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\ Jer From Prentice-Hall & Catalytix 


An Interactive 
‘C’ Tutorial 


What Others Say 


‘“... unqualified recommendation. ’’ 
].P., Tennessee 
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..a better learning environment than ever.’’ 


Data Training Magazine, April 1986 
‘“...an excellent alternative to live instructors.” 
Walter Zintz, Editor-at-Large, UNIX / World 
ital 


~ 


Interactive 
The Interpreter gives you fine control over the execu- 
Two Integrated Parts tion and: debugging of a C program or fragment. A 


program can be stopped at any point and the values 
of active variables can be inspected and changed. 
Program modifications are effective immediately with- 
out waiting for compiling, assembling and link edit- 
ing. Function calls, statements, and expressions can 


be t 
2. The C Trainer Tutorial Textbook. e traced separately or together 


1. A powerful C Interpreter for designing, 
debugging, and executing your programs; 
plus an On-Line Library of complete C 
programs. 


Comprehensive Affordable & Widely Available 


: 1. The Interpreter runs on a variety of systems; here 
The C Trainer, written by Alan Feuer, takes you 


are a few: 

through the development of a collection of C pro- 9 
grams. The programs range from introductory to Macintosh and IBM PC/XT/AT (DOS) $9 
advanced; they illustrate the features of C using mod- Sun 2 or 3—$195 
ern programming practices. Included with the Tuto- ote 2 MicroVAX (UNIX or VMS)—$195 
rial are chapters that examine in depth various aspects Ry n& Pyramid and Gould —$595 
of C, such as expressions, declarations, initializations, AS S\ AT&T 3B/2—$145 3B/5—$195 
arrays and pointers, and macros. © se VAX/780 (UNIX or VMS)—$395 

(> > 2. the C Trainer Tutorial Book — $22.95 


The C Trainer programs perform useful tasks which Se 
illustrate a variety of important algorithms. 
Advanced topics include: 


3. Shipping Charges — $5.00 (within U.S.) 


* co-routines * recursive descent parsers 
- binary trees - finite state automata Production Quality Software Tools 
¢ dispatch tables ¢ semantic networks For UNIX and VMS 


‘indirect pointers _« tail-recursion elimination 
Save time and help automate software: 


¢ Design ¢ Integration 
To Order C Trainer Write or Call: * Prototyping * Testing 
¢ Coding ¢ Maintenance 
Catalytix Corporation 


55 Wheeler Street Call (617) 497-2160 for complete details 
Cambridge, MA 02138 
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PAINLESS WINDOWS. 


Windows. Data Entry. Menus. 
Finally,a C programmers’ tool that makes 
them as easy to use as printf). 

With Greenleaf DataWindows”™, 


you move in quantum leaps! 


GEE Snazzy Window Treatments a 


DataWindows represents an important 
breakthrough in C programming tools. It 
sets you free so you can create exciting 
programs quickly and easily, saving both 
time and money! Developed to work with 
the IBM PC, XT, AT, compatibles, and 
MSDOS or PCDOS, DataWindows is a 
carefully tooled system of C functions which 
will jazz up your programs with 
unprecedented efficiency. 


Greenleaf DataWindows is integrated 
windows, transaction data entry, pop-up, 
pull-down, and Lotus style menu systems 
with: 
@ Screen Management. You don’t have to 
remember what’s on the display or the 
sequence in which you put it there. 
DataWindows does the grunt work. 
There are no restrictions. 


@ Transaction Data Entry. Data entry 
windows can have any number of fields 
with sophisticated options for reading 
many data types. Calls are made to help, 
validation, and other functions. Full 
featured text editing, protected and 
mandatory fields, dBASE type picture 
strings, context sensitive help, validation 
of fields and transactions, redefinable 
keys, password entry, attribute control, 
keyboard idle and much more. 


= Device Independence. It detects the type 
of display adapter your computer is using 
and adjusts to it automatically for CGA, 
EGA, or monochrome. Logical video 
attributes are easy to use for color or 
monochrome. 


= Compatibility. Runs with Microsoft 
Windows and IBM TopView. 


@ The Greenleaf Tradition of Quality. Reliable 
products. Professional documentation that 
gets you up and running quickly and 
keeps you there. Reference card. 
Newsletter and Bulletin board. 


IBM, Microsoft & dBase, are registered trademarks of International 
Business Machines, Microsoft Corporation & Ashton-Tate respectively. 
PCDOS, IBM PC, XT, AT, & TopView are trademarks of IBM; MSDOS 
and Microsoft Windows are trademarks of Microsoft Corporation. 


Sanne Stop Window Shopping ae 


Order Today. Or call toll free for a free 
demo of the windows library that makes 
all the others obsolete. 


Order any of these high performance 
tools by calling your dealer or 
1-800-523-9830 today. Specify compiler 
when ordering. Add $8 for UPS second 
day air, or $5 for ground. Texas residents 
add sales tax. MasterCard, VISA, P.O., 
check, COD. In stock, shipped next day. 


Greenleaf DataWindows $225 
DataWindows Source Module $225 
The Greenleaf Comm Library v2.0 $185 
The Greenleaf Functions v3.0 $185 
Digiboard Comm/4-II $325 
Digiboard Comm/8-II $535 


GRREENIEAF 
S pauline’ 
1411 LeMay Drive, Suite 101 
Carrollton, TX 75007 
Call Toll Free 
1-800-523-9830 
In Texas and Alaska, call 
214-446-8641 
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Hees Vindow Dressings Eas 


@ Simple or Complex Windows. Up to 254 
powerful overlaid windows 
simultaneously, all with just one kind of 
window to remember! Yet any window 
can be from one character to 32K! 


@ Easy Window Operations. DataWindows 
lets you move, zoom, frame, title, change 
colors, titles, frames, size, location, and 
make windows visible or invisible at will! 
Functions set cursor, attributes, and write 
data to any window or “current window”. 
Word wrap, auto scroll, keyboard 
functions. 


@ Write to Any Window Any Time. Windows 
may be visible, overlaid, or invisible, and 
you can write to them anyway. What you 
write will be seen when the windows 
become visible. 

# DataWindows is fast! It writes directly to 
video memory (in some modes). 


@ Easy to save! Any window, complete with 
attributes, can be saved on disk quickly 
and efficiently. 


@ Source code available. No royalties. 
GS Also from Greenled: as 


The Greenleaf Functions v3.0 
The most complete, mature C language 
function library for the IBM PC, XT, AT 
and close compatibles. Includes over 225 
functions — DOS, disk, video, color text 
and graphics, string, time/date, keyboard, 
disk status and Ctrl-Break functions plus 
many more. 


The Greenleaf Comm Library 
Our 2.0 version is the hottest 
communications facility of its kind. Over 
120 functions — ring buffered, interrupt 
driven asynchronous communications for 
up to 16 ports simultaneously with 
XMODEM, XON/XOFF, many many 
sophisticated features. 


We support all popular C compilers for 
MSDOS/PCDOS: Microsoft, Lattice, 
Computer Innovations, Aztec, DeSmet, — 
and others. 
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hen large and complex software programs and systems 

are being developed on personal computers, effective 
management of the revisions and versions becomes critical. 
The POLYTRON Version Control System (PVCS) sim- 
plifies this process and lets you effectively control the pro- 
liferation of code changes. We used UNIX SCCS and RCS 
as models. However, our own experience, and the input 
of hundreds of PC programmers has enabled us to 
significantly improve upon these models. 


PVCS provides many powerful functions including: 
* Storage & Retrieval of multiple revisions of text. 
* Maintenance of a complete history of changes. 


* Maintenance of separate lines of development 
using branching. 7 


* Resolution of access conflicts. 
* Merging of simultaneous changes. 


* Modules can be retrieved by their own revision 
number, system version number, or specified date. 


* Efficient disk storage. PVCS uses a very intelligent 
difference detection technique that minimizes the 
amount of disk space required to store a new 
version. 


PVCS Maintains System Integrity 


PVCS prevents system corruption that could ordinarily 
result from security breaks, user carelessness or malfunc- 
tions. The levels of security can be tailored to meet the 
needs of your project. 


PVCS 


THE MOST POWERFUL AND 
FLEXIBLE SOURCE CODE 
REVISION & VERSION CONTROL 
SYSTEM FOR PCS AND 

LOCAL AREA NETWORKS 


PROGRAMMERS, PROGRAMMING TEAMS, 
PROJECT MANAGERS, LIBRARIANS AND 
SYSTEM ADMINISTRATORS FIND 

PVCS INDISPENSABLE 


The Preferred Version Control System 


PVCS is now being used in personal computer software 
development environments at hundreds of high-technology 
corporations including: 


Hewlett-Packard 3 Com. 
GTE Data Services IBM 
Sperry ‘Texas Instruments 


Westinghouse Electronics 
Nestar Systems 


ROLM Corp. 
The Aerospace Corp. 


Maintains Source Code Written In ANY Language. 


Requires DOS 2.0 or higher. Compatible with the IBM PC, 
XT, AT and other MS-DOS PCs. 


Only PVCS meets the needs of Independent Programmers and Corporations. Once 
you standardize on PVCS, the “Logfiles” used to track and monitor changes are 
interchangable between any PVCS product. You will receive full credit for your 


initial purchase if you upgrade to a higher-priced PVCS. 

Personal PVCS — Offers most of the power and flex- 

ibility of the Corporate PVCS, but excludes the features necessary l Q 
for multiple-programmer projects. 

Corporate PVCS — Offers additional features to maintain source code 
of very large and complex projects that may involve multiple programmers. Includes 
“Branching” to effectively maintain code when programs evolve 

on multiple paths (e.g., new versions for different systems, or a 39 5 
new program based on an existing program). Single user. 

Network PVCS — Extends Corporate PVCS for use on Networks. File 


locking and security levels can be tailored for each project. 
5-Station License $1,000. Call (503) 645-1150 for pricing on 1000 


Licenses for more than 5 Stations. 


TO ORDER: VISA/MC 1-800-547-4000. Dept. No. 358. 
Oregon and outside US call (503) 684-3000. Send Checks, 
PO.s to: POLYTRON Corporation, 1815 NW 169th Place, 
Suite 2110, Dept. 358, Beaverton, OR 97006. 
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/*Editor’s Comment*/ 


C is a very elegant and orthogo- 
nal language — it has a number of 
rules with few or no exceptions. 
However, C does lend itself to 
abuse, particularly with regard to 
the layout of code and the choice of 
identifier names. As a result C pro- 
grammers require more discipline 
and management than do program- 
mers of other high-level languages. 
Let’s look at the potential problem 
areas. Identifiers are case sensitive. 
While this in itself is not a bonus, it 
is in keeping with C’s philosophy 
of not prohibiting something for the 
sake of prohibiting it. Of course, if 
you give a programmer a choice, 
eventually they will choose many 
or most of the options, leading to 
mixed case identifiers, and possibly 
identifiers with the same spelling 
but different case. One can even 
have identifiers such as If, Else, and 
While which won’t quite conflict 
with reserved words but are 
nevertheless confusing. 


Then there is the algebraic 
nature of the operators. C uses 
almost all-of the punctuation char- 
acters on a keyboard. In fact, the 
language has more operators than it 
does keywords. About the only 
punctuation characters not used are 
eo Sand ©". And-not 
only must we identify these opera- 
tors, they can be grouped together 
to form other operators whose 
meaning can be totally unrelated 
such as with !=, << and >>. C 
may be the closest thing to APL 
when it comes to writing obscure 
‘one liners’’. The operators them- 
selves can be hard enough to distin- 
guish and the task is even harder if 
Operators are not surrounded with 
white space. 
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For the most part, C can be 
written with very little or no white 
space. Even the if, while and 
for constructs require their argu- 
ments to be braced by a pair of 
parentheses forcing code such as 
if (i+1&&(j>>=6))... to be 
unambiguous. And if white space 
isn’t necessary, then lazy program- 
mers ‘soon start omitting it, and lazy 
managers let them. How often have 
you heard the excuse ‘*Well I had 
to fit the whole expression on one 
line and there was no room for 
spaces’’ or ‘““There was no room on 
the line since the statement was 
already indented 5 tabs.’’ True, C 
is a free format language but that 
doesn’t mean that white space is 
unnecessary. Given that any 
expression can be broken across 
source lines at any point between 
two adjacent tokens the language 
lends itself to reasonable format- 
ting. 


Another common problem is 
that of indenting. K&R established 
a reasonable approach to code for- 
matting using tabs. While a pro- 
grammer may fully understand the 
code they are writing, will they 
understand it a month later? Two 
months later? Six? Heaven help the 
poor maintenance programmer who 


Acknowledgements 


inherits their code. One strange 
thing about the software industry is 
that few software developers are 
around when it comes time to do 
maintenance. Maintenance _is 
deemed to be “‘beneath’’ develop- 
ers. That’s the task you give the 
new people on the project. It’s a 
necessary evil and not particularly 
challenging unless you call fixing 
code that has no comments or docu- 
mentation a challenge. 


It is quite likely that a 
Significant percentage of mainte- 
nance time is spent in trying to read 
code before the code can even be 
understood. As I stated, C lends 
itself to abuse but that doesn’t mean 
you have to abuse it. The language 
allows a responsible programmer to 
‘‘move mountains’’ and an undis- 
ciplined programmer to ‘‘create 
earthquakes’’. What some view as 
C’s biggest weaknesses, C’s disci- 
ples view as its strengths. You get 
out of a language exactly what you 
put into it so let’s start being 
responsible for the code we write. 
Besides doing what we are already 
paid to do, we would be saving the 
industry many millions of dollars. 
And then we would all win. 


— Rex Jaeschke 


Doctor C and Doctor C’s Pointers are trademarks of Rex Jaeschke. 
The C Journal is a trademark of InfoPro Systems 


MS-DOS is a trademark of Microsoft. 


POSIX is a trademark of IEEE. 


UNIX is a registered trademark of AT&T. 
PDP and DEC are registered trademarks of Digital Equipment Corp. 


~NEW! FROM _ 
BLAISE 
_ COMPUTING _ 


Today’s programmers 
need more than yes- 
terday’s tools. Re- 
quirements such as 
removable windows 
and ‘‘sidekickable”’ 
pop-up utilities 
are changing 
the face of pro- 
gram design. 
You need to fil- 
ter interrupts so ~ 
that other resi- 
dent programs 
still work. You 
need the ability to switch between 
multiple display pages and monitors. 
Today’s technical demands are almost 
endless, but C TOOLS PLUS gives you 
what you need. 


SOLID LIBRARY SUPPORT 


Blaise Computing offers you solid li- 
brary support that can meet all your 
demands and more. C TOOLS PLUS 
embodies the full spectrum of general- 
purpose utility functions that are criti- 
cal to today’s applications. 


Here’s just part of the PLUS 
in C TOOLS PLUS: 


@ C TOOLS and C TOOLS 2 compatibil- 


ity —two packages that receive rave 
reviews for quality, organization, usa- 
bility and documentation. 


@ FULL SOURCE CODE 


C Tools Plus 


For The Programmer 


Whose Alphabet 


Begins & Ends 
With “C” 


@ WINDOWS that are stackable, re- 
movable, that support word wrap and 
that can accept user input. 


@ INTERRUPT SERVICE ROUTINE 
support for truly flexible, robust and 
polite resident applications. 


@® MULTIPLE monitor and display 
support, including EGA 43-line mode. 


@ FAST DIRECT VIDEO ACCESS for 
efficiency that will not constrain good 
program design. 


@ DOCUMENTATION, TECHNICAL 
SUPPORT and attention 
to detail that have distin- 
guished Blaise Computing 
products over the years. 


C TOOLS PLUS supports 
the Microsoft (and IBM) 
3.00 and Lattice 3.00 C 


compilers and is just 
$175.00. 
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Also Available Are: 

C VIEW MANAGER — 
A kit for building data 
entry screens and menus. 
Begin by designing on- 
screen what the operator 
will see; call upon our 
library functions from 
your program to display 
the screens and retrieve 
the data. Just $275, in- 
cluding all library 
source code. 

C ASYNCH MAN- 
AGER — provides 
the crucial core 
of hardware in- 
terrupt support 
needed to build 
applications that 
communicate. It 
also includes the “XKMODEM” file-transfer 
protocol and support for Hayes-compatible 
modems. All source code is included for $175. 
C TOOLS & C TOOLS 2—an indispensable 
combination still available at a low price of 
$175, including all source code. See re- 
view in PC Tech y IN Journal, 6/85. 
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Publisher’s Platform 


This issue, the theme is free- 
standing C. Running without an 
Operating system has its own 
rewards and problems, and our lead 
article, by noted author and 
developer P.J. Plauger, is an excel- 
lent introduction to the entire con- 
cept. An interesting case study 
from Ken Milnes and George 
Loughmiller of Etak tells how they 
developed their Navigator’ ™ pro- 
duct. Anders Gezelius, Dan Lau 
and Anders Rundgren discuss the 
Intel-based development system 
compiler they have been working 
on. It is interesting to note that por- 
tability of C programs is not limited 
just to hosted environments. Here, 
Intel has an upwards-compatible set 
of microcontrollers so C_ code 
developed for one member of the 
family can, in large part, be readily 
ported to others. And finally, Paul 
Chien from Systems and Software, 
Inc. identifies some of the needs 
and considerations of developing an 
embedded system. 


This time we _ put the 
SPOT LIGHT on Sam Harbison, 
Director of C and Modula-2 pro- 
ducts with Tartan Laboratories, and 
co-author of the very popular text 
C: A Reference Manual, written 
with Guy Steele. Sam has some 
interesting things to say about 
optimization of C versus other 
languages and project management 
aspects of C programming. 


John M. Hausman, Tandem 
Computers’ representative on the 
ANSI Standards Committee 
discusses the interesting topic of 
‘‘Just what is the type returned by 
the sizeof operator and the 


strlen run-time library  rou- 
tine?’’. Since strings and objects 
can’t have a negative size, it seems 
that some type of unsigned type is 
in order, but which? Derived types 
have their use within C and the 
typedef statement is _ often 
under-utilized. And when people do 
use it, they simply create a 
synonym for some basic type 
instead of using it for its intended 
purpose; that of creating a meaning- 
ful synonym of some complex 


declaration such as K&R’s 
treenode example. 


Most C programmers who have 
heard of yacc think that it is some 
weird system utility of interest only 
to compiler writers. As Dennis 
Deloria points out in Part 1 of his 
tutorial series on yacc, it canbea 
very useful tool in writing code to 
handle free-format command-line 
processing within applications. As 
he suggests, many of us invent 
‘‘languages’’ without even realizing 
it. Get a copy of one of the cheap 
yaccs Dennis lists and program 
along. 


And finally, Tom Plum gives us 
his quarterly report on the happen- 
ings at the latest ANSI C Standards 
meeting in Atlantic City, which his 
company, Plum Hall, sponsored. 


Questionnaire Results 


A few issues ago, we published 
a questionnaire. The purpose was 
to find out about you — what your 
technical background and interest in 
C is, and what kind of articles you 
want to see in future issues of The 
C Journal. I'd like to thank all of 
(Publisher continued on p. 62) 
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Fastest C 
Development on Earth: 
Instant C version 2.0 


— Instant C’s NEW version 2.0 gives 
- you immediate (2 secs.) compilation 


and execution of large (15,000-line) 


_ programs, and the ability to link in 


external (commercial or your own) 
libraries in an interactive. Lattice 


— 3.0 or Microsoft 3.0 compatible, 


interpreter-like environment with an 


_ integrated full screen editor and 
- source level debugger. 


You'll get full K&R standard C 
fast (33 second sieve) execution 


_ speed, and debugging with source 


code animation, single-stepping, 
backtracing, and unlimited 


— conditional breakpoints. 


Instant C now supports multiple 
screens and graphic devices, run-time 
checking of pointer and array 
references, and includes a new 


- manual, expanded tutorial and 


reference section, and complete 


_ library source. 


NEW Blaise Tools Are Better Than Ever 
C Tools Plus 


Free yourself for more creative programming; stop worrying about hardware 
dependence. Handle everything from co-resident software requirements 
to multiple display pages and monitors with C Tools Plus. Filter interrupts 
so that other resident programs still work. 200 + well-documented functions 
control screen handling (direct to video adapter or BIOS calls, EGA text 
mode support including 43 line and multiple display pages — even handle 
multiple monitors), an unlimited number of pop-up, stackable windows 
with word-wrap, interrupt service routines, DOS directory and file han- 
dling, memory management and program control, string functions, and 
more. Source, no royalties. Lattice 3.0, MS C. 


PCDOS $139 


MacStyle Your C Programs Use Mac’s Friendly Interface 
with C Extender 


Invention Software has written a powerful library that lets novices and 


__ professional developers alike access the Mac interface with over 85 flexible - 


functions to extend, access, and integrate with the “Toolbox.” 
High and low level functions create windows, scroll bars, dialog boxes, 
menus, provide mouse support, and perform graphics printing with single 


_ function calls. NEW version 2.00 features ZOOM windows, marquis to 
_ copy screen image, double-click detect, search and replace multi-page 


printing, improved text-editing, save and recall MacPaint bit map, “bug 
alert,” modeless dialog support, and generic I/O routines. Compact code; 


Flexible Screen 
Development with 
SECURITY CHECKING 
and HELP SCREENS: 
ZVIEW Screen Library 


Use this field-sensitive tool to devel- 
op data entry screens and windows 
and provide run-time flexibility. 
Security level settings restrict inquiry 
or update of fields; multiple screen 
help display is available at screen 
and field level. You can also 
customize ZVIEW’s operation and 
make any field characteristic change 
during execution. 

ZVIEW gives you full control of 
attributes, colors, boxes, protected 
fields, scrolling, and more. Load 
screens from memory for fast 
response. Field support includes 
alpha, numeric, or alphanumeric data 
types, case conversion, range check- 
ing, and field comparison, and 
ZVIEW provides automatic data 
conversion to and from ASCII screen 


» format. For Microsoft C, Lattice 3.0, 


MSDOS $399 _ partial source tutorial provided, no royalties. Aztec, Megamax. Consulair, 


Lightspeed. 


Quickly Prototype User Interface and Incorporate Screens 
with Skylights 

Use Skylights to quickly design interactive prototypes, then include screens 
you develop in your finished application code; design demos or tutorials; 
even use with other languages (BASIC, Pascal, Assembly) through related 
DOS-resident interface utility. 

Skylights combines an intuitive screen/window/menu editor, run-time 
windowing, menu handling, and front-end support routines, and “Demo/ 
Tutorial Maker” program plus detailed low-level primitives. Supports a 


. variety of pointing devices (mice, tablets, lightpens) and allows more 


than one to be active at a time. Support for Lattice, Microsoft, Datalight, 


— CIC86, MWC, Desmet, Aztec, and Wizard. Bit-mapped graphics upgrade 
available. No royalties. 


PCDOS $359 


A NEW C STANDARD FOR SCREENS AND WINDOWS: 
C-SCAPE 


_ Setting a new standard for screen generation, C-scape turns your Dan 


Bricklin Demo Program screens into C code instantly. You can capture 


existing screens from 1-2-3, Turbo, or that old BASIC diehard and convert 
them to C in seconds. C-scape can save you immense effort and reduce 
errors for both new program development and language conversion 
projects. 


C-scape is a combination screen generator and library of input/output 


_ functions that provides an advanced and powerful ability to create different 
__ types of menus, input fields, help screens, and text with unprecendented 
_ speed and flexibility. Tiled, pull-down, and pop-up windows of virtually — 
any depth (limited by RAM) are a key feature, along with scrolling, full 
color and type support, and individual key or field validation. 


Because C-scape is based on C’s printf statement, you can embed the 


: commands for screen positioning and field definition right inside your 
____ format string. This helps you produce clear, readable code, which is easier © 
to maintain and change. 


Since full source code is provided, the standard library routines can be 


_____ tailored to meet your exact screen layout and keystroke handling 
-_—-—s requirements. — 
. All C programmers will benefit from C-scape’s readable, intuitive syntax, 

____ based on an extension of C’s printf function. Beginners willlearn by study- 
ing code generated from captured screens. Advanced programmers will 
enjoy C-scape’s ease of maintenance. Power programmers will appreciate 

the free source code provided at no additional cost upon registration. 


Oakland Group, Inc. features free updates, an on-line bulletin board 


_ for uses, and toll-free technical support. 


Escape the pitfalls of coding from scratch, and free up your time for 


__ creativity and productivity. Buy C-scape now and take advantage of the 
‘31-day review period: satisfaction guaranteed or your money back. No 

royalties. No license fee. Lattice 3.0, Microsoft 3.0 & 4.0. 
PCDOS $149 


and Aztec 3.2e. Supports EGA, 
color, and monochrome displays. 


PCDOS $189 


MAC $119 


Fast Source Debugger/Interpreter 
Plus 100% Compiler Compatibility 
Interactive-C ™ 
Full K&R standard interpreter with integrated full-screen editor and source 
debugger speeds execute-edit-resume cycle and features 100% compati- 
bility with Lattice and Microsoft compilers (even header files). Link in 
external libraries; no source code modifications are necessary. 

Why get only a limited debugger when you can get full source debugging 
with an interactive interpreter? Unlimited breakpoints, variety of stepping 
modes, direct execution mode (evaluate expressions, modify variables, 
invoke functions), run-time error reporting by line and column, continue 
from error without re-executing from start. 8087/287 support, and even 
allows display of program and ‘icedcer output on separate monitors. 
Lattice 2.x and 3.0, Microsoft 3.0 and 4.0. PCDOS $225 


Fast, Easy-to-Use Graphics, Royalty-Free: 
Essential Graphics 

Draw fast dots, lines, circles, arcs, rectangles, and box fills. Draw a bar 
or exploded pie chart or a shaded line graph with one function call. Use 
the font and clip-art manipulation routines with the 10 fonts included (up 
to 8 simultaneously), or choose from over 500 other fonts and clip-art 
sets available. 

Essential Graphics provides fast animation and graphic windowing using 
GET and PUT, and generates compact code. Demonstration programs 


_ and comprehensive manual included. S 
Supports IBM Color, EGA, and Hercules cards. Epson and Oki printers, 
Lattice, Aztec, C86, Desmet, MS C, others. No royalties. 


PCDOS $209 


Call for Your FREE 
C Programmer’s Directory 


800-421-8006 


THE PROGRAMMER'S SHOP 


128-E Rockland Street, Hanover, MA 02339 
Mass: 800-442-8070 or 617-826-7531 12/86 


ar Circle 103 on Reader Service Card = 


* mailbox 


Dear Editor, 


I have been using C in various 
UNIX environments for several 
years. Recently, I took a job with a 
large company committed to C in a 
non-UNIX environment. They are a 
DEC shop and use DEC’s 
proprietary operating systems. I was 
surprised to find C was so popular 
outside UNIX. What C-related 
development tools are available to 
non-UNIX DEC shops? Whenever I 
mention lint, nobody seems to 
know what I’m talking about. 


Bonnie Helms 
Boston, Mass. 


[Rex: C is popular outside of 
UNIX environments, so much so 
that it is no longer in the shadow of 
that operating system. This is 
attested to by the fact that an ANSI 
Committee is hard at work standar- 
dizing the language. In fact it is 
quite possible that as many as 50% 
of the C programmers out there 
have never touched or seen a UNIX 
system. Certainly, the percentage 
is very significant. On DOS-class 
machines, C has become the 
‘language of choice’’ for serious 
software development and many 
small and large companies are 
committing millions of dollars and 
many man-years to C projects. In 
the DOS market alone there are 15 
or so C compilers, 5 or 6 inter- 
preters, and 2 lints and countless 
libraries. 


While C is popular in the DEC 
marketplace, DEC also has quite a 
few other languages that are more 
popular, such as COBOL, 
FORTRAN and BASIC. Certainly, 
there is far less competition from 
software vendors. Although you 
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don't mention what system you are 
using I'll assume it's VAX/VMS. 
Two compilers are available: 
VAX-C from DEC and a native 
compiler from Whitesmiths, Ltd. 
(800) 225-1030. Whitesmiths also 
sells quite a number of cross com- 
pilers hosted under VMS. The only 
lint available is VMS/LINT from 
Wizard Systems Software (617) 
641-2379. DEC has no lint of its 
own. The Safe-C interpreter and 
run-time analyzer packages are 
available from Catalytix Corp (617) 
497-2160 as is their interpreter- 
based C Trainer tutorial package. 
There are a number of EMACS ver- 
sions around including one from 
Unipress (201) 985-8000. There are 
almost no third-party _ libraries 
since DEC has a well regarded set 
of layered products themselves. 


There are a number of DEC 
layered products that are useful in 
a C_ development environment. 
DEC/Shell provides a UNIX Shell- 
like environment and supports pipes 
and I/O redirection a la UNIX. It 
also includes a number of the UNIX 
utilities. The text editors LSE and 
TPU can be customized to be 
language sensitive and rumors per- 
sist of vi being ported. The TPA 
product is a profiler, something like 
UNIX’ prof and gprof utilities. 
Since lint began as a UNIX utility, 
it has taken quite a while to become 
known outside UNIX circles since 
UNIX and non-UNIX communities 
are typically mutually exclusive 
each resists the other. DEC's 
equivalent of SCCS is CMS and 
MMS is something like make. 


About the only company Still 
addressing DEC’s PDP-II custo- 
mers is Whitesmiths who provide a 
native and several cross compilers 


into and out of that processor 
series. ] 


Dear Rex, 


I am puzzled by the need for the 
typedef keyword. It seems that I 
can achieve the same affect using 
#define. Can you explain the 
difference? 


Jonathan Reynolds 
Ann Arbor, MI 


[Rex: Good question. It’s one I 
often get in seminars I teach. First, 
#define is a preprocessor direc- 
tive that allows substitution of any 
arbitrary string. This process takes 
place before the text is passed off to 
the compiler. There are no syntactic 
constraints on the text substituted 
provided that any tokens created as 
a result of substitution are syntacti- 
cally correct. typedef, on the 
other hand, is a C statement and it 
only allows syntactically complete 
and correct type declarations to be 
given synonyms. Logically then, you 
Should use typedef to name 
derived types and +#define to 
give names to string constants. 


While the two may be used 
interchangeably in many cases, 
there are type declarations where 
#define cannot be used. For 
example, — consider typedef 
char * STRING; and 
#define STRING char *. /f 
you have the declaration STRING 
ptr; the two are equivalent but 
with the declaration STRING 
ptrl, ptxr2; they are not since 
the typedef version creates two 
pointers while the #define ver- 
sion creates a pointer anda char 
variable. Another case is for the 
type ‘‘function returning a pointer 


to function’. For — example, 
typedef char ye EE ee 
PFPTRINT; declares PFPTRINT 


to be a function that returns a 
pointer to a function of return type 
char. You can't do this with 
#define.] 


SPECIAL OFFER For New Subscribers to 


THE Go OURNAL' 


Subscribe to the one magazine just for C programmers Cl YES! Please send me a full year of 
(hobbyist or professional) and software managers. ~~ The © Journal (four information- 
You'll get programming tips, software andbook reviews, | Packed issues) for only $18.00, a savings of more 
industry news, and reports on the ANSI Standards than 35% off the regular price. My check or credit 


ittee. ; work rw card information is enclosed. 

paso cen ihn absn anv ONE YEAR $28.00 $/8,20 

micro, mini, or mainframe computer. (Outside North America add $9.00 for airmail) 
Please charge my O) Visa CO) Mastercard 

2 yg ERE TOES RENAME ANR OMA oe TR | AIT Signature 
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Company v OAR I m yin Mi _ Address or AEE 

Cette ZO ENN IRM _ Phone 


For faster service on charge orders call TOLL FREE (800) 628-2828 ext. 849 
Our Guarantee: | understand my satisfaction is completely guaranteed or | will receive a full refund for all unmailed issues. 
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this postage-paid card. The 
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AREA CODE AND PHONE NUMBER processing. 

PLEASE CIRCLE ALL ANSWERS THAT APPLY TO YOU: 

1. DO YOU 2. Your years of experience 3. Operating system(s) you 100 101 102 103 104 105 106 107 108 109 
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[Editor’s note: To join X3J11, con- 
tact Dr. Plum at Plum Hall Inc, 1 
Spruce Ave, Cardiff NJ 08232, 
(609) 927-3770. To order the pub- 
lic review copy of the proposed 
standard, call Global Engineering 
Documents at 800-854-7179, or 
call the X3 Secretariat at 202-737- 
8888.] 


December Decisions 


The draft proposed ANSI Stan- 
dard for C began its four-month 
public review period on 7 
November 1986. The December 
1986 meeting of X3J11 made very 
few changes to this draft, mostly 
editorial clarifications. There are 
only two decisions of concem to 
the programming public. 


4.10.4.3: Because of _ the 
difficulties of handling return codes 
on various operating systems, the 
behavior of the exit function has 
been revised. Calling  exit(0) 
causes a success code to be 
returned, as before. However, all 
other exit arguments have 
implementation-defined semantics. 
In particular, exit(1) has always, 
and may in the future, indicate suc- 
cess on some (non-UNIX) systems. 


by Thomas Plum 
© 1986, Plum Hall Inc. 
All rights reserved. 


To provide for strictly portable 
code, two new macros are added to 
<stlibh>: EXIT SUCCESS pro- 
duces a value that means success on 
the target system, and EXIT FAIL 


produces a value that means 
failure. 
4.11.4.4: In the Internationali- 


zation arena, there are two minor 
changes. 


The function previously known 
as strcoll, which transforms a string 
into a locale-specific sorting key, 
has been renamed strxfrm, with a 
slightly revised calling sequence: 


Size--t. strxirm({ 
char: *t0, 
const char *from, 
Size t maxsize); 


There is a new function which 
directly performs locale-specific 
String comparisons, and it has been 
given the name strcoll: 


int -SELOOLE ( 
const char *sl, 
const char *s2); 


It behaves just like strcmp, except 
that it applies the locale-specific 


Meeting of X3J11 


collating rules determined by the 
setlocale function. [See ‘‘ANSI C: 


Internationalization,’ in the previ- 
ous issue of The C Journal. ] 
Schedule 


Depending upon the volume 
and nature of the public comments 
still to be received, the committee 
still expects a completed Standard 
for C by late 1986 or early 1987. 


[Thomas Plum is Chairman of 
Plum Hall Inc, and author of 
several books on the C language. 
As Vice-Chair of ANSI committee 
X3J11, Dr. Plum is designated by 
the committee to handle communi- 
cation to and from the public.] 
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Writing Freestanding 
C Programs 


P.J. Plauger, President, Whitesmiths, Ltd. © 1986 P.J. Plauger 
Introduction 


There are four general approaches you can take when writing a C program: 


Highly portable — so that it will run the same way on dozens of operating systems on many different architectures. 
Whitesmiths’ C and Pascal compilers, our program development utilities such as link and hex, and our text pro- 
cessing utilities like diff and sort are examples of programs coded with enhanced portability in mind. Portable 
Style is restrictive, but it can enable you to reach a broader marketplace for your products or retain hardware 
vendor-independence for programs used internally. 


Operating system specific — to take advantage of special features of some operating system, such as UNIX or 
IDRIS, which is otherwise machine-independent. Some examples are the shell sh and the file tree copier cp — 
both rely on system calls and file attributes that seldom have direct analogs on other systems. Code written in 
Operating system specific style can run on any implementation of whatever operating system it was written for, but 
must be reworked (often laboriously) for porting to other systems. 


System and machine specific — to take advantage of the features of some operating system on a specific computer 
architecture. In situations like this there is often a definite need to be met, and portability may not even be a con- 
sideration, as in coding something like an overlaid, real-time program that handles multiple asynchronous traps 
under RSX-11M+. It is often convenient, however just to be able to write such a complex program in a high-level 
language like C. 


Freestanding — to implement the operating system itself, or at least the operating environment. Obvious examples 
are programs like the resident portion of UNIX or IDRIS. A freestanding program need not be a general-purpose 
operating system; it can control anything from a household appliance to an oil refinery. 


In the first three cases, there is an operating system around to help you. All you have to do is type something like: 
prog -flagi -flag2 filel -file2 file3:>outfile 


and you can count on the operating system, or on a C language runtime support library, to do all of the following: 
1. locate the program prog in some file and load it into memory, 


2. make the arguments -flagl, -flag2, filel, file2, and file3 available as an array of NUL- 
terminated strings to the user-supplied function main(), 


3. ensure that a runtime stack is set up, as well as a chunk of memory that can be used as a heap, and that 
storage is cleared as needed, 


4. open the ‘‘standard input’’, “‘standard output’’, and ‘‘standard error’’ files, and ensure that the standard output 
file is redirected to the newly-created file outfile. 


call the main() function with the command line arguments described earlier, 


open files by name, upon request, and perform input/output to those files in a way that more or less hides any 
device peculiarities from your program, 


7. take a return from main() oracall to exit () as a request to terminate execution and return completion 
Status to the environment, and 


8. close any open files on program termination, so that they are properly represented on disk (if necessary), and 
give control back to the command interpreter or some other agent. 
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\4 COMMON LISP Development System for Your PC or AT 


Introducing TransLISP PLUS ' The Consultant’s LISP 
Over 400 Primitives, a C Interface, and Optional Runtime System 


People call you because you're an expert. Your customers want to keep up with what’s going on. They want software that is more intelligent 
and responsive, or software that does something that just wasn’t possible before. So they call you. 


Now you can write and deliver a whole new category of software with TransLISP PLUS, a practical, efficient LISP: system. You can also 
add Artificial Intelligence to your software. We include several features, like a C Interface and Optional Runtime System, so you can 
control the performance and security of your programs. And your users only need to have a PC (can even be non-compatible) with 320K 
and | floppy drive. Now, what could you write for a $700 PC? . . . or a $7000 PC?.. . 


— 


Add AI Technologies to 
Your Software 


Most of the programs you write are accessed 
by a user who doesn’t have your expertise. 
Use intelligent interfaces to make your pro- 
grams more responsive to the end user. 

You can even use the C Interface included 
with TransLISP PLUS to customize LISP, or 
combine C functions with LISP programs. 

Take advantage of AI technologies to make 
your programs smarter and more flexible. 


Extensive Development 
Environment 
Over 400 Primitives 


TransLISP PLUS provides you with over 400 
primitives for development, including extras 
for hardware support and operating system 
access. Their spectrum ranges from control 
constructs, macros, and special forms, to 
multi-dimensional arrays, reader support for 
binary, octal, and hex constants, improved 
list processing, and system interrupts. 

DOS commands and applications can be 
invoked from within TransLISP PLUS, as 
can the fast editor. Of course, you can use 
your own editor if you like. 

A variety of debugging tools are provided. 
The trace facility tracks the evaluation of any 
built-in or user-defined function or macro. 

Traceback, Break, Cross Reference, and 
Pretty Printer are also provided to help you 
spot problems. 


¢ Over 400 COMMON LISP Primitives 
Optional Runtime (No Royalties) 
Interpreter 
Program Editor 


Many Debugging Utilities 

Microsoft Mouse Support 

Supports IBM PC color graphics 
Supports 8087 math coprocessor 
Over 30 Demo Programs with Source 


Use TransLISP PLUS to program with and deliver to lots of machines . . . Use your existing 


Clibraries... Distribute your applications 


MONEY BACK GUARANTEE 


The ONLY Full Featured 
Common Lisp with a 
C Language Interface 


The best of both worlds. The interface to 
Microsoft C gives you a powerful extension 
to TransLISP PLUS — now you can write code 
in LISP and C. And you don’t need an AT, 
it will run on your PC! 

The C Interface makes it practical for you 
to write a C program and add it as a new func- 
tion to TransLISP PLUS. Your function can: 

* extend and/or change the LISP syntax 
¢ be an entire system of programs 

Create your own BUILT-IN primitives which 
are directly tied to the system and called at 
full speed by the interpreter. Extend the 
functionality of your program by including 
features of your own like macros, functions, 
and special forms. 

Code from C libraries produced by other ven- 
dors can be integrated into your program to 
perform tasks not normally part of LISP. 


Use PLUS for Your 
Applications. No Royalties. 


Once you own TransLISP PLUS, you may 
want to use it to distribute applications. No 
problem. 

The Optional TransLISP PLUS Runtime 
supplies you with a special interpreter. You 
can distribute an executable version of your 
program without distributing source code. 

The Runtime is available for $150 and Trans- 
LISP PLUS is required. 


* C Language Interface 

¢ Complete Manual with Tutorial, Indexed 
Reference Manual, and Quick 
Reference Card 

* Online Help 

¢ Lexically scoped 

¢ Use your C Libraries 

¢ System Interrupts 

¢ NOT COPY PROTECTED 


Try TransLISP PLUS ($195) for 30 days — if not 


satisfied get a full refund. 
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Don’t Know LISP? 


Get a solid understanding of LISP with the 
comprehensive, easy-to-understand tutorial. 
Each section walks you through a new concept 
and reinforces it with examples — both text 
and online. 

Over 30 demo programs supplement the tuto- 
rial. Use them for an in-depth introduction 
to LISP programming techniques, Commented 
source is included so you can see how and 
why the program operates. 

The demos cover a wide variety of applica- 
tions including: Select a word processor, Read 
dBASE SDF files, Job Counselor, and many, 
many more. 


The Fundamentals 


If you are interested in learning LISP but don’t 
need all the extras in TransLISP PLUS, order 
TransLISP for $95. It’s a full, easy-to-use 
introduction to LISP that includes the tutorial 
and demo programs described above, and over 
300 primitives. 

It is a solid subset of COMMON LISP; and 
you can write programs of up to 12000 lines. 


COMMON LISP Standard 


Programs written carefully with TransLISP PLUS will be completely 
“portable” to any other COMMON LISP system on a micro, mini, 
or mainframe computer. This allows you, for example, to wnte a 
program with TransLISP PLUS on your PC at home, and compile 
and run it on the VAX at work. 


System Requirements 


TransLISP PLUS requires 320K RAM and a 360K disk drive. 
TransLISP requires 256K RAM and a 360K disk dnve. 


PransLasr. PLUS 2S 5 eee $195 
ATANSLASE =.) RE lS $ 95 
Upgrade TransLISP to PLUS ... $158 
TransLISP PLUS Runtime ..... $150 


TO ORDER OR FOR DETAILS CALL 


800-821-2492 Ss 


Solution 


ystems ” 


335-E Washington Street, Norwell, MA 02061, (617) 659-1571 


TransLISP and TransLISP PLUS are trademarks of Solution Systems. Solution Systems is a trademark of Solution Systems. 


That’s a lot of services, which illustrates why operating systems are so important. Even when writing system- 
and machine-specific applications, you still get quite a bit of portability. For example, you can do console I/O on 
any 8086 running MS-DOS, regardless of the chips used to implement the console driver and regardless of the 
brand of terminal hooked to that driver. You can write a file to disk on a given system the same way regardless of 
whether the disk is a 3-inch floppy or a 50 MB Winchester. This is what operating systems are all about. 


So why would anyone want to write a ‘program any way other than on top of an operating system? We’ve 
already cited two good cases: you may be writing the operating system itself, or your application may not warrant a 
general-purpose operating system, for whatever reason. A toaster or a traffic light does not need a multi-user 
environment. In some cases, you have to do at least some of those things described above for yourself, because 
there’s nothing else around to do them for you. With this in mind, our next step is to revisit the operating system 
services outlined above with an eye toward eliminating the need for them. 


Startup: the Powerup ROM 


A powerup ROM is a read-only memory that doesn’t lose its contents when power to the processor is switched 
off. When power is restored, or when a reset occurs, the hardware automatically directs the processor to begin exe- 
cution at some address within the ROM. Registers are seldom set up that don’t absolutely have to be, so the first 
business of a powerup ROM is to establish a reasonable working environment. If the goal is to pass control to a C 
program as soon as possible, the minimum that could be considered ‘‘reasonable’’ is to set up a stack, initialize pro- 
gram data, and call the main() function of the C portion. 


A ‘‘stack’’ is a writable chunk of RAM (Random Access Memory) used to memorize where C left off in a given 
function every time another function is called. Usually, the arguments are written to the stack before the call, and 
any auto data objects are allocated on the stack on entry to the called function. This chunk of memory is called a 
stack because of the method by which it is used. The last “‘frame’’ of autos, arguments, and memorized informa- 
tion is always the first one to be removed when the function returns. This is sometimes called a LIFO (for last-in- 
first-out) discipline — the chunk of memory behaves just like a stack of cafeteria trays. 


C is a powerful language, but its power does not extend to setting up its own stack. It may take only a few 
machine instructions to set up an environment in a powerup ROM, but the instructions are important and are seldom 
expressible in C. 


This startup problem is not unique to freestanding programs, by the way. Every operating system interface Whi- 
tesmiths provides (even for UNIX systems) contains an assembly language “‘C header,’’ with a name like chdr or 
Crts, that gets control initially from the operating system and makes an environment more palatable to C. It may 
even have to set up a stack, if the system hasn’t provided an adequate one for the C environment. The difference is 
that the runtime library can provide one for you, knowing the underlying operating system. There is no way of 
knowing the particulars of a given freestanding environment, however, and as a result compiler vendors cannot pro- 
vide customers with such interface support. 


So the startup code for your freestanding program must set up a stack and call some function in your C program. 
That function need not be called main(), by the way — that is just the longstanding convention for initiating a C 
‘program you might want to stick to the convention to ease debugging in a hosted environment, as described below. 


Once you’ve solved the problem of calling your C program, you still have some tough issues to address. Where 
do you lay out the stack? Where do writable data objects go? Where in memory does the ROM reside? Usually, the 
answers are imposed by hardware limitations (a polite term for decisions made before the programmer was con- 
sulted). Whitesmiths’ program development tools, for example, are prepared to deal with most of the variables that 
programmers writing ROM-based programs must deal with. 


A C program consists of ‘‘functions,’’ which are bodies of executable text that each have a single entry point, 
and “‘data objects,’’ which are contiguous blocks of memory used to represent data values. Conceptually at least, a 
compiler generates all executable text for functions into a ‘‘code section’’ and all data objects into a ‘‘data section.’’ 


The Whitesmiths linker allows you to specify the starting addresses of the text and data sections to control relo- 
cation of the image so that the program will run properly wherever the ROM is placed in memory. Note that link 
doesn’t actually produce a full memory image with the text and data sections properly scattered about within it. 
That is the job of the hex utility, which communicates with a piece of hardware usually called a ‘‘PROM program- 
mer’’ (for Programmable Read-Only Memory programmer), which produces the actual read-only devices. link 
just makes sure that the code is properly relocated and that the relocation biases are recorded in the object file 
header. hex reads object files and produces Intel standard ‘‘hex’’ files (or Digital Research variants, or Motorola 
S-Records, as appropriate), which are digestible by most devices used to program ROM chips. 
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Thus, you can arrange to have your C program linked with the assembler startup code, have everything relocated 
to run wherever the ROM is placed in memory, and to have the resulting image presented to a PROM-programmer. 
The startup code must set up a stack in an area of RAM before calling the main C function. 


Should the main C function return, or “‘exit’’ be called, the best thing to do, as a rule, is to start all over again. 
That’s the standard behavior of a ROM-based system. 


The only remaining issue concerns what to do about the data portion of the C program. This is where data 
objects go when they are declared to be of the types extern or static. 


To initialize the data portion, you will have to do the following: copy the initialized data portion of your pro- 
gram from wherever you placed it in ROM to wherever you told the linker to relocate it in RAM, and zero out the 
‘““BSS”’ area, if present. The BSS (for Block Started by Symbol) area is sometimes used to lay out static data 


objects for which no explicit initial values, or all zeros, are provided. C requires that all such data objects be set to 
all zeros. 


Of course, you can avoid either or both of these steps in certain cases, but both are required as a general rule. 


Also as a general rule, you must depend upon the linker you use to: provide you with the sizes and addresses you 
need to help in writing this code. 


Until recently, C provided no way to distinguish parameters and tables (which never vary during program execu- 
tion) from data objects with important initial values, or data objects that need not be initialized. Everything had to 
go into the data section. Now there is a const type qualifier, which can be used to identify those data objects that 
are never modified. A C compiler can thus place all const data objects into the code section, assuming the target 
machine doesn’t separate text and data address spaces. In some cases, the compiler can even generate a third 
‘‘literal’’ or ‘‘read only data’’ section which is distinct from both code and writable data. 


There is almost always some need for initialized data that will vary later on, however. The safest thing to do, 
therefore, is to assume that there is a data section consisting of data objects with important initial values — and, 


therefore, that an initial image of the data section must be copied from someplace in ROM to the expected addresses 
in RAM, at program startup. 
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Implementing the logic to do this copying is not a major burden. At program startup, a freestanding C program 
must have its stack set up — for autos, arguments, and function call linkages. It is just a bit more work to copy the 
initial data image. Whitesmiths’ linker,-for instance, is easily instructed to relocate the data section for its eventual 
RAM destination, while the hex utility can place it following the text section in ROM. link can also be 
instructed to define symbols at the end of the text section and the end of the data section in its output file. An ini- 
tialization routine to copy data from ROM to RAM can therefore simply step through memory from the ‘‘end of 
text’’ symbol until ‘‘size of data’’ bytes have been moved. 


If there is a lot of data to be copied, you can tie up a lot of ROM, and a lot of address space, with the initial 
image of initialized data. You might also find the copying time at startup time unacceptably long. There are ways 
to decrease the amount of data that must be initialized this way, sometimes to none at all. First there are literals — 
character strings, switch tables, and constants — that the compiler generates of its own accord. On a machine that 
supports separate instruction and data spaces, literals must be steered into the data (or constant data) section. But on 
machines that use just one address space, a good compiler will let you steer all constant data into the text section. 
(Naturally, Whitesmiths’ code generators fall into this category.) It is rare that a ROM-based system also uses 
separate instruction and data spaces. 


Similarly, extensive tables that are known to be read-only can be declared as const as mentioned above. Or, 
for backward compatibility with older versions of C, they can be collected into one C source file and compiled or 
prelinked with special options to place all data declarations for that file in the text section. 


If the remaining data objects can be contrived to require no initialization at startup, or to require only a simple 
initialization, such as all zeros, then the data section can simply be discarded at ROM-burning time. Or, if your 
compiler stores all such data into a BSS section, as described above, then the initialized data section will be empty. 
All your startup code need do in this case is zero out the area of RAM set aside at link time for the BSS section. 


Of course, to make sure that all initialized data needs only zero initial values, all the source code must be avail- 
able for scrutiny. One case where this is not possible is when library functions, available only in binary, are incor- 
porated into a ROM-based, or sharable, product. Whitesmiths’ libraries contain no unnecessary barriers to being 
shared. A function such as exp, for instance, contains only tables in its data section — it may safely be passed 
through the linker to have its data merged into its text section. 


Some functions of necessity, however, contain static data objects with important initial values. Usually these 
functions interact with operating system services and hence are not found in ROM-based programs. Examples of 
static data in the libraries are onexit/exit, which remembers the head of a list of functions to be called on pro- 
gram exit, and open/close, which holds the current state of open files. Still other functions with static data 
objects may be useful in freestanding programs — a prime example is the set of heap management functions that 
includes malloc/free. 


Whitesmiths’ latest compiler for System/370 collects all static storage for the runtime library in one area. The 
startup code allocates space for this area, sets it to zero, and writes its address into an otherwise unused general 
register. Any library function that needs static storage knows to locate it via this general register, and knows that its 
initial value is zero. Thus, with some very special coding, the System/370 library is sharable, or ‘‘reentrant’’ in 
IBM parlance. 


The library you have to use may not have been crafted with this exquisite care. And for the libraries you write, 
it is often too hard to determine which library functions are safe, and even harder to remember special rules for 
keeping new code safe. The best practice, therefore, is to adopt the most general startup initialization described 
above. If you keep to a minimum the amount of data that must be initialized at program startup, you will get a very 
acceptable ROM-based C program. 


The Bootable Image 


A bootable image is a freestanding program designed to be read (usually by a powerup ROM) from a known 
place on a disk, diskette, or tape into a known place in memory. It can also be “‘downloaded”’ over a serial link, for 
instance, by a powerup ROM; the records output by the hex utility are usually ideal for this purpose. Once loaded 
into memory, by whatever means, control is then transferred to a known place in the image. For example, when 
you turn on or reset an IBM PC, the powerup ROM checks system integrity and then attempts to read in a bootable 
image from diskette A:. This is how PC-DOS (or whatever) gains control. Another example is the MACSbug 
ROM that Motorola provides for the MC68000 family that lets you download Motorola S-records. 


Actually, a bootable disk image may be so limited in size that all it can do is read in yet another bootable disk 
image, which may in turn load still another. The same basic principle applies. All these cases are essentially the 
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same as the bootstrap ROM. About the only difference is that usually you don’t have to copy the data area any- 
where because it’s already copied into RAM. Otherwise, the startup sequence is the same. 


Note also that the best way to debug your own powerup ROM program is to use somebody else’s to load yours 
as a bootable image. This results in a shorter development cycle than going through a PROM-programmer. 


The Minimal System Interface 


Besides Starting up a program, an Operating system offers a number of useful services during program execution. 
The Standard C library provides a very extensive set of functions that enhance these services. Almost every pro- 
gram can be made better and simpler by making use of the C library. 


The problem is that many of these functions require at least a primitive version of some operating system ser- 
vices to be useful. To use a given C library in a freestanding environment, you need to know the low-level func- 
tions that the rest of the library calls upon to interact with the operating system. Some compilers are specialized for 


hosted operation under one operating system. These are very nice to use in that environment, but have libraries that 
are difficult to adapt to a freestanding environment. 


Since Whitesmiths C is designed to be highly portable, the required interface for any given environment is quite 
narrow. Listing 1, for example, contains the set of functions you must provide to run a C program that makes use of 


the Standard C library. It assumes that all you want to do for input/output is read and write to a control console, so 
many of the low level functions are simply dummies. 


There are three bits of “‘magic’’ required to make all this functional: 


<exit to containing environment> 


does whatever you want on program exit. Typically, you would go back to where main() returns in the startup 
code. The exit status can simply be ignored. 


<get a character from console> 
does whatever it takes to read a character from the console device. A simple device handler that just hangs until the 
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#define FAIL -1l 
#define NULL (void *)0 
#define STDIN 0) 
#define STDOUT 1 
#define STDERR 2 
typedef void (*FNPTR) (); 
void terminate(); 
static FNPTR next = {(FNPTR)& terminate}; 
int< eLoset). 1retorn <PAtiy 
void exit (status) 

int status; 

{ 


<exit to containing environment>(status) ; 


} 


char * getenv() {return (NULL); } 


ses oh ie Sil © frecurn-(0)3 °F 


long. -iseek{() {return {bAIL); 5 
FNPTR _onexit (pfn) 
FNPTR (*pfn) (); 
{ 
extern FNPTR next; 
FNPTR oldfn; 


oldfn = next; 


next = (FNPTR)pfn; 
return: toldtn): 
} 


VOLO ONnIMe rt) at rd 


{return (FAIL); } 
{return (FAIL); } 


int _open() 
int _rawmode() 


int -read(fd, buf, size) 
ane 2203 
char *buf; 
int size; 


{ 
if (fd == STDIN && size) 
{ 
xbuf = <get a character from console>() ; 
return (1); 
} 
return (FAIL); 
j 


{return: (FAIL); } 
{return (FAIL); } 


int _remove() 
int rename () 


void * sbreak (incr) 

unsigned int incr; 

{ 

char *newp, *oldp; 

static union { 
double d; 
char area[1024]; /* or whatever heap size you need */ 
} heap; 

static char *hstart = {(char *)&heap}; /* start of heap */ 


incr += incr & ((int)&((struct {char ch; double d; } *)0)})-—>d - 1); 

newp = hstart + incr; 

if (newp < ((char *)&heap)[0] || ((char *)&heap) [1] <= newp) 
return (NULL); 

oldp = hstart; 

hstart = newp; 

return (oldp); 

} 


void (* signal ()) () {return (0); } 
int system() {return (0); >} 


void terminate (status) 
int status; 


{ 
extern FNPTR next; 


while (next && next != (FNPTR)& terminate) 
next = (FNPTR) (*next) (); 
_exit (status) ; 


j 


unsigned long _time() {return (0b); “} 
char * uniqnm() {return ("x"); } 


int write(fd, buf, size) 
Tit tc: 
char *buf; 
int size; 
{ 


register unsigned int i; 


if (fd == STDOUT || fd == STDERR) 
{ 
for (1 = size; i; --i1) 
<put a character to console>(*buf++) ; 
return (size); 


} 
return (FAIL); 


} 


Listing 1 


17 e THE C JOURNAL 


next character is typed invariably looks something like this: 


while (<input port not ready>) 


return (<input from port>); 


<put a character to console> 


does whatever it takes to write a character to the console device. A handler of equivalent power to the console 
reader above is: 


while (<output port not ready>) 
<write character to port>; 

if (<character is a newline>) 

<put a character to console>(’\r’); 


Naturally, any of these magic sequences can be made fancier, by using device interrupts, for example, but these 
get the job done. The code in _sbreak() is designed to ensure that any area allocated is on a storage boundary 
constrained enough to hold any data object in C. Understanding it is educational but not vital. 


Given a system interface like this, you are now in a better position to debug your freestanding program first as a 
hosted program, before you go to the less helpful environment of the target system. To do this, just compile and 
link the program with the native library so your console becomes the normal “‘standard input’’, ‘‘standard output’’, 
and “‘standard error’’. You can then type at the program and see what it types back at you, or feed it a canned 
script by redirecting the standard input file until you get the proper responses, or capture the responses in a file by 


redirecting the standard output from the command line, for later comparison with the expected output. 


In short, you can do all of the things you do to debug your program under control of an operating system. Of 
course, any code that touches special hardware, such as device registers or display memory, may have to be avoided 
or stubbed out, but there is usually lots of code you can check out as if it were a conventional program. 


For operation on the target, relink the program object files with your freestanding header and your new system 
interface, plus the portable C library as before. You may not need some of the functions shown above — with a bit 
of experimentation you can determine the necessary requirements for each freestanding program. 


The dummy functions are most useful in the debugging phase. You can have all sorts of code that works right 
only when hosted and need not worry about removing it when linking for freestanding operation (at least not until 
you elect to reclaim the space in ROM). You might even have your startup code call the main C function as: 


Static char *av[2] = 
{"freestanding", NULL}; 
main(l, av); 


The program can thus inspect av [0] to determine which environment it is running in. 


Conclusion 

Writing freestanding programs is often made harder than it has to be. The techniques described here ease the job 

by: 
1. letting you write as much of your code as possible in C, 
2. giving you much greater use of the portable C library, 
3. helping you debug more in a hosted environment, and 
4. standardizing the structure of freestanding programs. 


The important thing to note is that all of the facilities provided in a hosted environment are useful, in some form 
at least, in a freestanding environment. Instead of saying, ‘“How can I live without that?’’ you should ask, ‘*What 
form do I want that facility to take?’’ Then, and only then, are you ready to write nontrivial freestanding programs 
without fear. 
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e Mar 9-13 ANSI X3J11 meeting 
in Boulder, CO (Host AT&T). 


e Apr 27 -- May 1 DECUS US bi- 
annual Symposium in Nashville, 
TN. 


e Jun 8-12 ANSI X3J11 meeting in 
Paris, France (Host COSMIC). This 
will be a joint meeting with the ISO 
C Standards Committee. 


e Sep 14-18 ANSI X3J11 meeting 
in Boston, MA (Host Whitesmiths, 
Prime, and others). 


e Dec 7-11 ANSI X3J11 meeting 
in Phoenix, AZ (Host Motorola). 


e Dec 7-11 DECUS US bi-annual 
Symposium in Anaheim, CA. 
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Embedded System 
Programming 
Considerations 


Introduction 


C is a good choice of a high 
level language in an embedded sys- 
tem. It allows the programmer 
enough flexibility such that little 
assembly code should be required. 
Modern compilers are available 
which generate fast and compact 
executable code, further reducing 
the requirements for assembly code. 


C was successfully used to 
develop the software for the Etak 
NAVIGATOR ™ The NAVI- 
GATOR is a vehicle navigation 
computer which displays a digital 
road map on a vector display in a 
passenger vehicle and navigates 
along the road network to position 
the vehicle at the correct place on 
the map. Additionally, a destination 
may be entered by street address, 
and the NAVIGATOR will display 
a star at the destination location. 
All of the software was written in C 
and assembly code using an IBM 
PC/AT running PCDOS as_ the 
development computer. The 
NAVIGATOR uses an Intel 8088, 
with 256 KB of random access 
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memory (RAM) and 16 KB of read 
only memory (ROM). A cassette 
tape is used to store the navigation 
program and the map database. 


The choice of the development 
environment when writing pro- 
grams for an embedded system is 
one of the most important decisions 
to make. Developing the programs 
on a computer which uses the same 
instruction set as does the embed- 
ded system will reduce the amount 
of time required to debug the sys- 
tem. By using the same instruction 
set, much of the executable code 
may be debugged on the host 
development computer where the 
debugging tools are generally supe- 
rior. In many cases the actual 
application program may be run on 
the host development computer in 
real-time. After choosing the host 
development computer, a C com- 
piler must be selected. Most com- 
pilers are designed to generate code 
which will run in the host comput- 
ers environment. To port this code 
to an embedded system, some 
modifications will be required to 
the C startup functions to account 


for the differences between the host 
and target environment. Some 
compilers are designed specifically 
to generate programs for an embed- 
ded system. These compilers do 
not make assumptions about the tar- 
get environment and will supply 
documentation on what is required 
by the startup code to execute the C 
code. 


The Etak Navigator software 
was developed using a compiler 
which was designed to run under 
PCDOS. This facilitated efficient 
debugging because of the high-level 
tools available such as symbolic 
debuggers and file and screen I/O 
systems. All of the program 
modules which were not specific to 
the embedded system could be 
debugged using these tools without 
having to execute the programs on 
the embedded system. By using 
this type of compiler, some special 
problems had to be solved. A pro- 
gram had to be written to convert 
the executable code to hexadecimal 


+ NAVIGATOR is a trademark of Etak, 
Inc. 


SAPIENS V8: 
A VIRTUAL MEMORY MANAGER FOR THE PC 
EXPAND YOUR COMPILER 8 MEGABYTES 


Sapiens V8 is a virtual memory manager for C pro- 
grammers on the IBM PC™, built for speed and 
reliability. 

Sapiens V8 is structured around a least-recently-used 
paging system. The unique design of the virtual 
memory paging & storage scheme makes it an invalu- 
able tool for C programmers. 


HERE’S WHY: 


Sapiens V8 is for C programmers who want to develop 
PC applications that go beyond current memory re- 
strictions of the PC and a 16 bit architecture. 


Don’t re-invent the wheel! 


Sapiens has spent 1.5 programmer years designing, 
coding, enhancing, and rigorously testing V8 in real 
world systems. V8 frees the programmer from the low- 
level bookkeeping necessary for managing the virtual 
workspace, allowing greater productivity. 


With an 8Mb workspace and stack & heap libraries, 
Sapiens V8 solves the problems and hazards of stack & 
heap overflow. 


V8 provides you with a powerful, fast, virtual memory 


__ software architecture which emulates an 80386 memory 


management system. Sapiens V8 is fully implemented 
in software. It is not dependent on add-on boards or 
special chips, and runs on the 8086, 80286, and 80386 
machines. 


Sapiens Software is committed to C programmers and 


to the advancement of high level programming capa- 
bilities in a micro environment. 


oe” 


Sapiens V8 is the first step into the next phase of the 
micro revolution, bringing the power, speed and 
complexity of a mainframe virtual memory manager 
to your PC. 


* FAST! LESS THAN 10% speed overhead 
¢ Provides 8 Mb virtual memory workspace 


¢Link V8 libraries to C compilers—Muicrosoft™, 
Lattice™ & Aztec™., 


¢ Advanced software emulation of a 64 bit architecture 


¢ Virtual stack library supports stack frame manage- 
ment and multiple return values 


¢ Virtual heap (vmalloc ()) allows allocation of very 
large data structures 


¢ System requirements: Huge model C compiler, V8 
uses 22-128 Kb core Hard disk recommended. 


AND THERE’S MORE! 


The Make you’ve been waiting for... 

Sapiens Make is another fast and powerful pro- 
erammer’s tool from Sapiens Software. Sapiens Make 
is fully compatible with UNIX™ Make. Sapiens Make 
is a program maintenance utility which saves hours of 
programming time by tracking which parts of your 
source code need updating. 


Microsoft is a trademark of Microsoft Corporation. IBM PC, is a trademark of 
IBM Corporation. Lattice is a trademark of Lattice Corporation. Aztec is a 
trademark of Manx Software. UNIX is a trademark of Bell Laboratories. 


I’m excited about Sapiens V8 and want to order NOW! 


Please send me: 
copies Sapiens V8 @ $300.00 each 


copies Sapiens Make @ $79.00 each 


sets Sapiens V8 and Make $339.00 pkg. 


(indicate if for O Aztec 


0 Microsoft O Lattice) 


0 Please send me information about other Sapiens products. 


PACH Seis ee ee ee a Company 
PROROTGSS 3 Co oe epee ee ee one 
D1 RRS De RMR SEDO E IS OS, me J ent be eter plaaiien ds tataerce ts YC ZAP 


Make check or money order payable to: Sapiens Software Corporation. VISA/MasterCard accepted. 
Mail to: Sapiens Software, P.O. Box 7720, Santa Cruz, CA 95061-7720 Telephone: 408/458-1990 
All prices include shipping & handling. California residents add 6.5% sales tax. 
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such that a ROM can be pro- 
grammed. Little documentation 
was provided by the compiler ven- 
dor on what was required to initial- 
ize the system before the C code 
could be executed. 


A discussion of the differences 
between the environment of a host 
Operating system and an embedded 
system follows: 


Startup code 


Before the main function of a C 
program is executed, the operating 
environment of the computer must 
be initialized. A routine must be 
written to do this initialization and 
then call the function main. After 
main returns, (if it does), a routine 
must be provided for the C program 
to return to. The functions of the 
startup code may include: 


1. Establish a stack for the pro- 
gram. 


2. Zero uninitialized data. 


3. Establish and initialize the 
heap. 


Check memory requirements. 


Setup segment registers (for 
Intel 8088/8086) 


Command line processing. 


Open stdin, stdout, and 
stderr 


8. Initialized any special 
hardware such as a floating 
point processor. 


9. Call to function main. 
10. Exit from main. 
11. Close any open files on exit 


In an embedded system, many 
of the above items may not be 
required. For example command 
line arguments most likely will not 
be used. To rewrite the startup 
code, it will be useful if the source 
code of the compilers startup code 
is available as a starting point. 


Establish a stack for the pro- 
gram: Various compilers and com- 
piler models place the stack in dif- 
ferent. places. The particular 
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environment in the embedded sys- 
tem may place some constraints on 
the placement of the stack. Care 
must be taken to maintain compati- 
bility with any stack checking 
which the compiler does at the start 
of each function or to disable the 
checking via a compiler switch. 


Zero uninitialized data: All 
uninitialized data is normally 
zeroed before the main program is 
executed. The location of these 
areas may be determined by exa- 
mining the load map and deducing 
the segment names or by example 
in the compilers startup code or 
documentation. 


Establish and _ initialize the 
Heap: If the heap is used by the 
program (calls to malloc, cal- 
loc use the heap), it must be esta- 
blished in the startup code. In 
some cases this is done by initializ- 
ing some global variables which 
define the start of memory where 
the heap will reside. The startup 
code for the compiler will provide 
an example of how to initialize the 
heap. 


Check memory requirements: 
Before the main program is exe- 
cuted by the startup code, a check 
is made to insure that enough 
memory exists for the program to 
successfully run. This check may 
not be required with an embedded 
system. 


Setup segment registers: 
Depending on the compiler and 
compiler model used, the segment 
registers (DS, ES, SS) must be ini- 
tialized. This is the responsibility 
of the startup code. See the docu- 
mentation for the particular com- 
piler on what these variables must 
be set to. 


Command line processing: If a 
command line is appropriate for the 
embedded system, the variable 
argc and array pointed to by 
argv must be initialized, and then 
passed as arguments to main. 


Open stdin, stdout, and 
stderr: If these devices exist in 
the embedded system, they must be 
opened before main is called. 


Initialize any special hardware 
such as a floating point processor: 
This initialization may be done in 
the startup code or by the boot code 
of the computer. 


Call to main: This is the 
point where the user’s main pro- 
gram is executed. 


Exit from main: If the main 
program ever returns, an exit rou- 
tine must be provided. This routine 
follows the call to main. 


Close any open files on exit: If 
a file system exists, then exit nor- 
mally will close any files which 
were left open. 


Segment Relocation 


When a host computer executes 
a program, the executable code is 
retrieved from a disk file and placed 
in memory. In many cases, the 
code will require segment reloca- 
tion. That is to say, some of the 
address information must _ be 
modified based on the loaded pro- 
grams location. Linkers generate a 
fixup table which specify the offsets 
into the load module where reloca- 
tion is required. In the case of code 
which is in read-only memory 
(ROM), the fixups must be applied 
to the program before the ROM is 
programmed. If the program is 
going to reside in random access 
memory (RAM), then the fixups 
may be applied before or after it is 
loaded into memory. If the 
memory address where the program 
will reside can not conveniently be 
the same every time, then it is 
necessary to apply the fixups after 
the the program is loaded into 
memory and the location of the 
code is known. 


A program fixup is generated by 
the linker whenever a call to an 
absolute memory address is encoun- 
tered or when a reference to a code 
or data segment is made. The fixup 
table is a list of pointers into the 
program which reference absolute 
memory addresses. The linker gen- 
erates op codes with the assumption 
that the program will be loaded at 
absolute memory address OOOOH. 


When the base address of the pro- 
gram is known, then this value is 
added to the values pointed to by 
the fixup table. 


The following listing (Listing 1) 
is a code fragment which will use 
an MSDOS fixup table to apply 
fixups to an unmodified EXE file. 
See the DOS Technical Reference 
manual for details on how a DOS 
EXE file is laid out and the struc- 
ture of the header attached to an 
EXE file. 


Read Only Memories 


The major consideration which 
must be kept in mind when writing 
programs to run in ROM is the data 
variables. Programs normally have 
initialized and un-initialized data 
areas. The initialized data will be 
included in the EXE file and must 
be programmed into the ROM 
along with the code. The startup 
code in the ROM must move this 
initialized data to the memory 
address where the data will eventu- 
ally reside. This data area is nor- 
mally at the beginning of the data 
segment, but does not have to be. 
A review of the linker’s load map 
will reveal where it resides for a 
particular program. 


C programs do not normally 
modify any of the code during run 
time. If it is required to do this for 
some reason, the code must be 
moved to RAM for obvious rea- 
sons. 


C Library Routines 


C provides many convenient 
I/O services such as file I/O and 
screen I/O. In many embedded sys- 
tems these are not required. The C 
file and screen I/O can take up as 
much as 5 to 10 KB of code, so it 
is desirable to delete these routines 
from the executable code. In prin- 
ciple, it should be easy to delete 
these routines by not making any 
calls to the functions which do the 
WO (read, write, printf, 
scanf, etc.). It is often not as 
simple as this. Some compilers 
include a label in the object 


modules to force the DOS startup 
code to be included at link time, 
which will force much of the I/O 
system to be included. For exam- 
ple, the Microsoft C compiler 
includes the label _acrtused. 
Microsoft declares _acrtused in 
the startup code astart. By 
simply declaring this label else- 
where in your code, the Microsoft 
startup code will not be required. 


The Computer Innovations C86 
compiler will force much of the I/O 
system to be included if stdio.h 
is included in any of the modules. 


If the compiler vendor supplies the 
source code for the run time 
libraries, it is possible to customize 
it to suit the particular application. 
For example the sprintf and 
sscanf functions are useful even 
if an I/O system is not present. In 
many cases floating point is not 
required by the applications. This 
code may be deleted if it is not 
required and will save substantial 
memory. lf; -Uusprinté.:.cor 
sscanf are used, they must be 
modified to not use floating point. 


es! There is a 


firm that can meet your needs" 
across the board in software 
quality control and management! 


Who!? Software Research, Inc. 


We are the hi-tech software quality control firm. We specialize in a// matters of 
software quality control and reliability. From production line controller code to 
PC software distribution, and from simple one-user applications to highly 


complex control systems. 
SR has skills and experience in: 


() product evaluation and testing, quality enhancement 


L) compatibility and regression testing 


L] language validation, touch tests, and performance tuning 

CL] reliable systems design and guality control 

L] medical and critical applications testing 
SR’s services are top notch, based on the latest methods and techniques — 
supported by our advanced software tools. With people trained and supervised 


by experienced technical professionals. 


SR’s tools can help you directly: 


(1) SMARTS™ to organize and run regression tests 

1 TCAT™ to measure module test completeness 

1) S-TCAT™ to measure system test coverage 

1) CAPBAK™to capture and play back tests 

11 TDGEN™ to generate test cases and data 
Software Research is the pioneer in software quality management. We've served 
business, research, and governments around the world since 1977. 
Interested? Call or write us today for more information. 


Software Research, Inc., 625 Third Street, San Francisco, CA 94107-1997 
Phone: (415) 957-1441 Telex: 340-235 (SRA SFO) 
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/* this function will use the fixup table to modify the op-codes 


in a PCDOS 
been made 


exe load module. 


1) Output of the linker has not been modified. 7 
2) This function compiled under large model (pfixup must 


be a far pointer). 


=] 


relocate (fixup, codebase, numfixup) 


short baseaddr; 


short *fixup[]; 
short numfixup; 
{ 
short *pfixup; 

pfixup = fixup; 
while (numfixup-—) { 


/* segment address of 


The following assumptions have 


beginning of load module */ 
/* array of fixup entries */ 
/* size of fixup array */ 


*pfixupt+ += baseaddr; 


} 


One useful trick for resolving 
link problems where too much of 
the C library is being pulled in, is 
to delete from the compiler’s run 
time library the functions which are 
not desired. The linker will then 
specify which labels are unresolved 
and which functions are requesting 
them. This should lead to the 
problem’s identification. 


Debugging 


One of the most important 
aspects to consider in an embedded 
system is debugging of the execut- 
able code on the target hardware. 
The availability of terminals, 
printers and powerful debugging 
tools such as symbolic debuggers 
and dumping programs greatly 
accelerates debugging on the host 
development computer. However, 
because of the inherent differences 
between the host environment and 
that of the target, not all bugs can 
be caught at the host level, and 
some debugging must take place on 
the target hardware. With the 
proper design of both hardware and 
software, the amount of time spent 
debugging on the target system can 
be minimized. 


As previously discussed, choos- 
ing a development computer which 
has the same type of processor as 
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the target system, simplifies debug- 
ging in that’ the actual 
compiled/assembled code iS 
debugged on the development com- 
puter. Additional steps can also be 
taken on the host computer to sim- 
plify debugging. For instance, it is 
desirable to interface the target peri- 
pherals to the host computer. In the 
Etak system, an interface board for 
the IBM PC was developed for the 
vector display device, and most of 
the development and debugging of 
the display driver and map display 
software was completed prior to the 
availability of the target hardware. 
Other peripherals can be mimicked 
by the resources available on the 
host computer. For example, the 
Etak database is stored on cassettes; 
however, for program development 
on the host computer the database 
is stored on the hard disk. 
Requests for database on _ the 
development computer are simply 
redirected to disk. 


Efforts should be made to keep 
the differences between the host 
and target versions at the lowest 
levels of the software. In_ this 
manner, the number of modules 
which differ from host to target ver- 
sions can be minimized and 
confined to special libraries, those 
for the development computer and 
analogous libraries for the target 


hardware. To switch from a host to 
a target version of the program is 
then simply a matter of linking with 
a different link file which includes 
the appropriate libraries. 


Whereas the above steps can 
minimize the time spent debugging 
on the target, bugs will crop up 
when the program is ported to the 
target hardware, and some debug- 
ging must take place on the target 
hardware. One of the most power- 
ful tools which can be used in this 
task is an in-circuit emulator (ICE) 
which replaces the processor giving 
the user access to the CPU registers 
and memory while allowing the 
system to run at its normal speed. 
An ICE allows the user to set con- 
ditional breakpoints, examine and 
modify program memory as well as 
data, and trace program execution 
and memory address contents. In 
addition, code can be disassembled 
and the program may be altered by 
assembling directly to the target 
memory. Many of the emulators 
allow symbolic addressing and still 
Others allow debugging at the 
source language level. 


While the use of an emulator 
greatly facilitates debugging of the 
executable code on the target 
hardware, it does however have 
several drawbacks. The high cost 


of an emulator makes it prohibi- 
tively expensive to install an emula- 
tor in more than a few systems, 
therefore, an alternate means of 
debugging on the target hardware 
must be available. In a system as 
complicated as the Etak Navigator, 
some bugs have a mean time 
between occurrence of hundreds of 
hours or thousands of miles in the 
case of a vehicle computer. This 
necessitates some form of a resident 
debugger. 


In order to debug on the target 
system without the aid of an emula- 
tor, some sort of interactive display 
device must be available. This can 
be something as simple as a front 
panel display register, though a 
monitor is preferable. If the target 
hardware does not include a moni- 
tor it may be possible to design the 
hardware such that a monitor can 
be added to selected units. Once a 
monitor is available, a simple 
debugger can be quickly added to 
the executable code allowing the 
user to interactively examine and 
modify memory. In this manner, 
bugs which occur infrequently can 
be captured and analyzed without 
relying on an ICE. More sophisti- 
cated debugging tools such as 
breakpoints, dump routines, data 
checkers, etc. can also be imple- 
mented for analyzing problems and 
performance. An asynchronous 
serial communications adapter is 
very useful to provide communica- 
tions between the host and target 
computers. This will allow down- 
loading of test programs and dump- 
ing memory images from the target 
computer. 


Inevitably, a complicated piece 
of software will contain fatal bugs, 
i.e. problems which require the sys- 
tem be reset through intervention of 
the hardware. To accomplish this, 
the hardware must monitor the 
activity of the software and assert 
the reset line on the processor when 
things are not in order. In the Etak 
system, the hardware monitors 
write commands to an I/O port and 
reset the processor when no activity 
has occurred for a specified amount 
of time. An analogous software 


function, known as watchdog code 
(see ‘‘Software fault tolerance 
staves off the errors that besiege 
microprocessor systems’’, Dick Jar- 
rett, Electronic Design, August 9, 
1984) can be implemented to 
enhance the hardware function. The 
watchdog code is set up to test not 
only the time interval spent in a 
section of code, but also the 
Sequencing of the code. The error 
detection is done by monitoring the 
activity of various parts of the main 
program and all of the interrupt 
routines. If a sequence error or 
loop timing error ‘does occur, then 
the software will stop writing to the 
special I/O port, thus causing the 
hardware to activate the reset line. 


By integrating the on-board 
debugger into the watchdog code 
such that the debugger is automati- 
cally called up when a watchdog 
problem is detected, an extremely 
valuable tool is available for 
trapping these fatal bugs. In the 
Etak system, the interrupt routine 
which monitors the various watch- 
dogs freezes as much of the system 
as possible and immediately calls 
up the debugger. In this manner a 
postmortem can be performed on 
the failed code. The values for all 
of the registers and flags at the time 
of the interrupt are displayed so that 
the routine which was executing at 
the time of the interrupt can be 
determined. The stack can be 
examined so the local variables can 
be determined and the sequence of 
function calls can be traced back. 


The time spent in developing 
onboard debugging tools on the tar- 
get hardware is paid back many 
fold by accelerating up the debug- 
ging process. The original coding 
for the Etak debugger was accom- 
plished in less than a week. The 
watchdog trap feature enabled the 
capture and analysis of fatal bugs 
which would have taken months of 
driving in an emulator-equipped 
system. 


Ken Milnes is a senior engineer 
at Etak, Inc. He is responsible for 
navigation, communications, and 


cassette operating system software 
development in the NAVIGATOR. 


George Loughmiller is a senior 
engineer at Etak, Inc. He is . 
responsible for navigation, display, 
database and debugger software 
development in the NAVIGATOR. 
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BASICA 


C,TURBO 


Automatically BAS__PAS, 
BAS__C converts not only 
BASICA to Turbo,C but spaghetti 
code to indented, scoped, struc- 
tured program (CASE,REPEAT, 
WHILE,SWITCH,IF-THEN). 
Deadcode listing. Dealers welcome. 

Demo $5 30 day money back. 

$85 + $5s/h($15 oversea) 
Gotoless Conversion 

Box 50068, Denton, TX 76206 

Phone (214) 221-0383 
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Developing Embedded 


iIAPX-86 Systems in C 


This article addresses the impor- 
_ tant issues of writing C programs 
for embedded system applications. 
The issues are: ROM code genera- 
tion, software integration for target 
hardware, mixed language develop- 
ment, C language extension for 
iAPX-86 architectural support and 
high-level debugging. 


C — the Language of 
Choice ' 


Software is the key to the suc- 
cess of today’s microprocessor 
based products. The increase in 
functionality of today’s 16-bit and 
32-bit microprocessors coupled 
with the increasing pressure to 
shorten time to market have dic- 
tated the use of high-level 
languages to improve productivity. 
C is the high-level language of 
choice for today’s microprocessor 
development projects. 


C is traditionally used in a 
RAM-based host environment 
where a well defined run-time 
environment exists. Program testing 
can be easily done by executing the 
program on the same system on 
which it was written. 
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However, this is not the case for 
systems with embedded micropro- 
cessors such as microwave oven 
controllers, automotive electronics, 
computerized instrumentation, etc. 
These applications are normally 
stand-alone systems. That is, an 
embedded system has no operating 
system or environment to support a 
user interface or file system. There- 
fore, the use of C for microproces- 
sor system development, implies a 
whole new set of challenges. 


When selecting a C program 
development support system for an 
embedded application, the usual cri- 
terion of good code generation, etc. 
is no longer sufficient. The designer 
must now look for an environment 
that addresses code generation, soft- 
ware integration for target system, 
and debugging into an integrated 
package. 


Embedded System 
Requirements 


This section addresses the spe- 
cial requirements for developing 
embedded microprocessor applica- 
tions. 


The C compiler should produce 
efficient code in terms of memory 
Space utilization. and execution 
speed. In real-time applications, 
execution speed is of primary con- 
cem. For such applications, the 
compiler should also provide the 
option of code generation optimized 
for execution speed rather than code 
SIZe. : 


Most C compilers are designed 
for use with RAM-based applica- 
tions running in environments such 
as UNIX and MS-DOS. As far as 
these C compilers are concerned, a 
program is partitioned into three 
sections: code, data and stack. The 
machine instructions generated are 
placed in the code section. All 
extern and static variables 
(initialized and uninitialized), literal 
Strings and floating-point constants 
are placed in the data section. The 
function parameters and auto 
variables are placed in the stack 
section. This scheme works fine in 
an environment where the program 
is stored in secondary storage and 
the program is loaded into RAM at 
run-time. 


Embedded systems, on the other 
hand, require the code section to be 


placed in ROM. Moreover, all con- 
stant data and literal strings must be 
placed in nonvolatile memory as 
well. To do this, the compiler must 
generate a special data section for 
code to be placed in a ROM. 


The compiler should also have 
the capability to differentiate 
between volatile data (data that can 
be changed) and nonvolatile data 
(constants that never change and 
thus are normally in ROM). All 
nonvolatile data variables should be 
declared with the const type 
modifier (as introduced by the pro- 
posed ANSI Standard). The effect 
of the const modifier is to 
prevent any assignments to the 
object, or other side effects such as 
increment or decrement. That is, a 
const object cannot be used as an 
Ivalue. 


The compiler should provide 
clear and concise error messages to 
assist the user to pinpoint program 
errors easily. In order to facilitate 
modular programming, the compiler 
must also provide type checking 
across all program modules. This 
can be done using the proposed 
ANSI Standard function prototype 
facility. 


Mixed Language 
Programming 


An application may make use of 
existing object libraries and/or 
real-time kernels such as the Intel’s 
iRMX and Systems & Software, 
Inc.’s (SSID REX-80/86, that are 
written in either assembly or PL/M. 
Thus, a common object format is 
essential in order to provide a 
mixed-language interface. One such 
format is Intel compatible Object 
Code Module (OMF) format. 


In embedded system applica- 
tions, it is often necessary to handle 
interrupt requests. These, and I/O 
programming and hardware specific 
functions dictate the use of assem- 
bly language in programming these 
functions. 


iIAPX-86 Architectural 
Support 


The iAPX-86 family of 
microprocessors uses a segmented 
memory architecture. The 20-bit 
address bus of the microprocessor 
can access up to 1 MB of memory. 
A memory address is constructed as 
a four-byte quantity. The high-order 
two bytes are the base part and the 
low-order two bytes are the offset 
part. The 20-bit physical address is 
computed as follows: the base value 
is treated as a 20-bit value with a 
low nibble (four bits) of zero. It is 
then added to the offset value. 


The base value is placed in a 
segment register which indicates the 
base address of a 64K-byte physical 
segment. All the memory locations 
within the segment may _ be 
specified with the offset value. For 
example, if the data segment regis- 
ter DS contains the value 2489H, 
the DS points to the physical seg- 
ment with the base location 
24890H. An offset value of 5H 
specifies the physical location at 
24895H. 


There are restrictions on 
hardware addressing using this 
scheme. The compiler should gen- 
erate code using various memory 
addressing assumptions, called 
memory models. These provide the 
programmer with the ability to 
select the combination of efficiency 
and addressability needed for a par- 
ticular application. Six possible 
memory models are shown in Table 
Li 


Pointers 


It is desirable to be able to 
specify explicitly the nature and the 
size Of pointers and the pointer 
arithmetic scheme, disregarding the 
memory model in effect; and also 
to specify which segment register is 
to be used as the frame for 2-byte 
pointers. 


Support for the proposed ANSI 
type modifiers such as const and 
volatile would be useful as 
would be support for the following 


#1 Lint for MS-DOS 


The professional 
diagnostic facility for C 


PC-lint lets you zap swarms of C 
bugs and glitches at a time. 

Now you can uncover the quirks, 
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waiting to bite you. PC-lint finds 
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want ... in one pass. Set PC-lint 
to match your own style. 


Outperforms any lint at any price 


a Full K&R support and 
common ANSI enhancements 
(even MS keywords) 

# Finds inconsistencies 
(especially in function calls 
across multiple modules!) 

= Modifiable library descriptions 
for 8 popular compilers ) 

= Super fast,one-pass operation | 

= Suppress any error message 

# Zillions of options 


@ PRICE $139-MC+-VISA*COD 
) Includes USA shipping and handling. 
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Tiny 64K, less data 


Small 64K bytes 

Medium 1M bytes 

Compact 64K bytes 
1M bytes 
1M bytes 


| Model | Maximum Code |___—- Maximum Data 


64K, less code 

64K bytes 

64K bytes 

64K Static, 1M Local 

64K Static, 1M Local 

1M bytes (Static and Local 


Table 1 


addressing modifiers: default 
Memory Model addressing (no 
modifier), near pointer, far pointer, 
_ds pointer (same as near), _es 
pointer, Ss pointer, _cs pointer. 


Note that _ds is fully equivalent 
to near for data pointers in the 
Tiny, Small and Medium Memory 
Models. Similarly, _cs is fully 
equivalent to near for function 
pointers in the Tiny, Small and 
Compact Memory Models. Data 
pointers in the Compact, Large and 
Huge Memory Models are 
equivalent to far pointers. Function 
pointers in the Medium, Large and 
Huge Memory Models are 
equivalent to far pointers. 


As discussed earlier, the 8086’s 
segmented memory architecture 
uses a base/offset pair to specify a 
memory location. There are restric- 
tions on hardware addressing when 
using this scheme. If an instruction 
uses an index register and offset to 
address, say an array element, the 
offset and index register value will 
be added together, but if the result 
exceeds 64K no carry bit is retained 
and the actual resulting location is 
quite different from that intended. 


The 8086 instruction set does 
not include suitable instructions to 
easily compute segment/offset com- 
binations where the offset exceeds 
64K. The problem is that any carry 
from the offset must be propagated, 
not to the low order bit of the seg- 
ment; but to bit 12. In addition, 
because of the wrap-around prob- 
lems of referencing offsets in struc- 
tures when the index register value 
is high, one must severely restrict 
such references. 


It is also desirable to to be able 
to specify explicitly those functions 
that use near or far returns and 
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calls, regardless of the memory 
model in effect. 


Input/Output 


The C language itself does not 
support I/O, hence the I/O library 
that comes with the compiler 
should provide functions that per- 
form the 8086-specific I/O opera- 
tions such as performing byte/word 
I/O to I/O ports. 


When dealing with objects 
directly mapped to memory I/O 
locations, the compiler should inhi- 
bit code optimization. This can be 
done using the proposed ANSI type 
modifier volatile. For exam- 
ple: 


extern int y; 


/x 
memory mapped I/O port 
7 


extern volatile int x; 


main () 


{ 


2 Bs & age Bet 


/* 

no optimization allowed 
Since the contents of 

x may change 
asynchronously to the 
program 


a 


]oo= oe? 
ET pee 
jae See 


/* 

should perform 
optimization since y 
remains constant and 


4 Si ToOtvolsts te 


x / 

1 = y; 
i= y; 
SS a 
} 


It is desirable to have functions 
that are designed to be used to han- 
dle the 8086 interrupt vectors. 
SSI’s C compiler (XC86) allows an 
interrupt handler to be declared 
with the ‘‘interrupt’’ language 
specifier. An interrupt function 
saves all registers on entry and 
restores them on retum. A far 
pointer to an interrupt function may 
be stored directly into an 8086 
hardware interrupt vector. 


The XC86 C compiler package 
Supplies a portable run-time source 
library that provides three macros 
and two functions to facilitate inter- 
rupt handling. They are: 


* void disable() — the 
disable macro generates an 
interrupt disable instruction. 
Only the non-maskable NMI 
interrupt will still be allowed 
from any external device. 


®e void enable() — the 
enable macro generates an 
interrupt enable instruction. 


This allows any device interrupt 
to occur. 


* void geninterrupt (int 
interrupt number) — the 
geninterrupt macro. will 
produce a software interrupt 
instruction with the specified 
interrupt_number. If the argu- 
ment is a constant, an INT 
instruction will be used. If the 
argument is the constant 3, then 
the special one-byte interrupt 
will be generated. If any other 
expression is given as an argu- 
ment, a more complicated 
sequence is generated that has 
the same effect. 


® void setvect (int 
interruptno, void 
(*far vector) inter- 
rupt ()) — setvect sets 


the interrupt vector’ entry 
corresponding to the interrupt 
type to the value in vector. 
C routines may only be used as 
an address passed to vector 
if the routine is declared to be 
an interrupt routine. It returns 
nothing. 


e void (*far getvect (int 
interruptno) ) inter- 
rupt () -—- . getvect 
retrieves the interrupt vector 
entry corresponding to the inter- 
rupt type. The return value is in 
fact a far pointer to an interrupt 
function. 


The compiler should also be 
able to generate in-line 8087 
instructions for high performance 
floating-point applications. 


Debugging Issues 


Debugging embedded systems 
programmed in C_ requires an 
approach different to that used with 
hosted applications. This is because 
the target machine is usually dif- 
ferent to the one being used for 
development. Furthermore, the tar- 
get system environments normally 
are stand-alone and do not support 
any operating system or user inter- 
face to facilitate program debug- 
ging. For example, the commonly 
used techniques of using printf 
is just not feasible. 


Until now, the most popular 
means for debugging target pro- 
grams was to use an in-circuit- 
emulator (ICE). An ICE provides a 
user interface that does not disturb 
the environment of the target. It 
further provides the capability to 
test hardware-dependent functions 
which can not be accomplished 
using a software-only debugger. 
Symbolic debugging is provided by 
ICE vendors to allow the reference 
of program variables using their 
symbolic names instead of the 
absolute hexadecimal addresses. 
Most ICEs give the designer an 
assembly  language-only view. 
Thus, a common scenario is to 
write program in C and debug it at 
the assembly language level. Worse 


yet, the lack of prototype hardware 
for use with ICEs, especially in the 
early stage of the project cycle, 
creates a bottleneck that may 
severely hamper the progress of 
project development. 


A symbolic debugging capabil- 
ity at the assembly level requires 
the designer to deal with machine 
level details that are error-prone and 
this severely limits the productivity 
gained from using C. Source-level 
debug capability gives the designer 
a much higher-level view. The 
designer should be able to track the 
program flow at the source level 
and verify the results of the pro- 
gram. variables. To do so, the C 
program variables must be refer- 
enced in the same context in which 
they were declared. 


Consider the case where we 
have an automatic structure. Space 
for it is allocated on the stack and 
its address is not known until func- 
tion invocation. This requires the C 
compiler to generate debugging 


information in terms of source 
module, variable names and their 
data types, etc. which can be used 
by the debugger. 


There are language level debug- 
ging tools that support a particular 
language such as C or Pascal. The 
debugging is done totally in the 
context of the language where the 
program was written. For embedded 
System applications, the capability 
to debug the program at both C 
level and assembly language simul- 
taneously is essential, since the exe- 
cution of a C program may have 
direct effect on the underlying 
hardware. For example, the write to 
a memory location which is used as 
a mailbox for inter-processor com- 
munication may Cause an interrupt 
request to be generated. Thus the 
designer must be able to view the 
program logic which manipulates 
the mailbox at C level and switch 
to assembly language level when 
the interrupt service routine has 
been initiated. 


The Great 
awk is now 
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Toolkit! 


Over 70 programs that perform tasks on machines like the us 
IBM PC, XT, or AT with the ease that one would expect 
while working under UNIX. Designed especially for those ur 
developing software ina DOS environment, these utilities . BRY\.., , 
include: SSS 
awk — data transformation & report generation language 
prof — give a profile of the execution times of a command 
egrep — find a string using full regular expression patterns 
diff — find the differences between two files 


cat chmod cmp comm cp cut date dd dev 
df du echo ed file find head help join 
Ic line Is more mv nm od paste pwd 
rm sed sh size sort split strings tail time 
touch tr uniq WC andmore ... 


The programs come with a shell and complete UNIX-style command-line file 
expansion on 3 DSDD 5.25” floppies, load and run under DOS, and are not 


name 


copy- 


protected. Phone support is available during business hours. Full documentation is 


included. 


Price: $139 from: Mortice Kern Systems 


Inc., 


43 Bridgeport Rd. E., Waterloo, Ontario Ned 24 


For information or ordering call collect: 


MasterCard & VISA orders accepted. OEM & dealer inquiries invited. 
UNIX is a trademark of Bell Labs. MS-DOS is a trademark of Microsoft Corp. 
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919-884-2251 


For real-time system develop- 
ment, the debugging process is 
further complicated by the fact that 
program flows are no_ longer 
sequential. Normal program flow 
can be interrupted by hardware 
interrupts and different program 
sequences can be initiated as a 
result. This type of system is typi- 
cally run under a real-time multi- 
tasking kermel. For such environ- 
ment, the designer must have access 
to the program execution history 
after the program breakpoint. 


The execution history informa- 
tion must include the program flow 
sequence displays in both C source 
and assembly language source. 
Furthermore, the designer must also 
be able to track the change history 
of certain program objects which 
may have bearing on the state of 
the system. 


Execution speed may be essen- 
tial to an embedded system in order 
to meet the real-time requirements 
dictated by the physical environ- 
ment it interfaces to. This puts a 
demand on the C compiler to 
Optimize the code generation for 
execution speed instead of smaller 
code size. 


Sometimes it may be desirable 
to pin-point a __ performance 
bottleneck and reprogram either 
using a different algorithm or 
perhaps in assembly language. An 
execution profiler may be used to 
record the time each module spends 
doing its thing and the results can 
be used to identify candidates for 
further optimization. 


Burning PROMs 


Once the C programs have been 
compiled, they have to be linked 
together, assigned absolute 
addresses and then bumed into 
PROMs. Since the C language pro- 
motes modular programming, an 
application is usually partitioned 
into multiple source files which 
have to be linked together. SSI pro- 
vides XLINK86 for this purpose. 


Absolute addresses are assigned 
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to the relocatable object module by 
the object code locator called 
XLOC86. The XLOC86_ locator 
supports a rich set of command line 
controls which gives you full con- 
trol and flexibility in the placement 
of the code, data and stack seg- 
ments of the relocatable object 
module anywhere in the 1M bytes 
of the 8086 physical memory. 
Moreover, a segment of bootstrap- 
ping code can be added to the 
resulting absolute object module. 


The XLOC86 locator generates 
an absolute object module. Most 
PROM _ programmers require the 
program code to be converted to an 
ASCII file in Intel hex format. The 
XOH86 formatter may be used to 
convert an absolute object module 
to an ASCII file in Intel hex format. 
A second formatter called 
TEKHEX is available which con- 
verts an absolute object module to 
an ASCII file in Tektronix extended 
tekhex format. 


Conclusion 


To support embedded micropro- 
cessor software development in C, 
the designer should look for an 
integrated C programming environ- 
ment with the following capabili- 
ties: 


e support both C and assembly 
language development. 


e support ROM code generation 
and locating of logical segments 
anywhere in memory as 
required by the target hardware. 


e the compiler should produce 
information that supports high- 
level source-directed debugging. 
The debugging information to 
support high level debugging 
should include symbol names 
and data types for all program 
objects, program statements and 
module names. 


e the environment should include 
a high-level debugger that sup- 
ports software development in 
high level language. . The 
environment should also sup- 
port hardware-independent 


debugging without the need of 
target hardware. This is_ best 
done by using a high-level 
simulator on the host. The 
simulation of target hardware 
simplifies debugging on_ the 
multi-user host and helps to 
eliminate the bottleneck created 
by the single-user ICE. 


for real-time system integration, 
ideally, the debugger is 
integrated with the ICE to pro- 
vide a high-level view for iden- 
tifying program algorithms and 
a low level view for checking 
out the software/hardware inter- 
face. 


Further Reading 


Improved C Compilers Boost Sys- 
tem Throughput, Harvey J. Hindin, 
Special Features Editor, Computer 
Design Magazine, pp. 54-61, Sep- 
tember 15, 1986. 


Debugging with Static Analysis 
Tools, Bob Jervis, Wizard Systems 
Software, Inc., The C Journal, 
Vol. 2 No. 2, pp. 22-26, Summer 
1986 


[Systems & Software, Inc. is a 
developer of tools suitable for 
developing embedded systems in C 
on various Intel microprocessors.] 


iRMX is a trademark of Intel. 
REX, XC86, XLINK8&6, XLOC86 
are trademarks of SSI. 
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Syntax Errors 


In Volume 2, Number 3 of The 
C Journal, a company called Oak- 
land Group, Inc. advertised a pro- 
duct called C-scape. The correct 
price for C-scape is $199, or $259 
with Dan Bricklin’s Demo Pro- 
gram. 
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Eco-C88 C Compiler: 


A full, professional C compiler with many ANSI enhancements at an 
unbelievably low price. 


C Programming Guide 
(Purdum, Que Corp.) 


The second edition of the B. Dalton bestseller. 
Perfect for those just getting started with C. 
Includes discussion of many X3J11 ANSI Standards 


* Prototyping, enum, void data types, plus structure passing & 
assignment * All operators and data types * Over 200 library 
functions * cc and mini-make for easy use * 8087 support * ASM or Committee recommendations. Many error messages 
OBJ output * Lint-like tiered error messages * Fast code * CED from Eco-C88 give page references to this book. 
editor (edit-compile-link from within the editor) * Expanded user’s Price is $20.00 plus $2.00 shipping. 
manual * Not copy protected * All for only $59.95! 

C Self-Study Guide 


M Eco-C88 Flexi-Graph Graphics Package (Purdum, Que Corp.) 


Everything you need to write dramatic graphics effects into your 
Eco-C88 C programs. 


* EGA, CGA, and Z100 support * Over 100 graphics functions (many 
are PLOT-10 compatible) * Most assembler support routines are 
outside small model code-data * Write thru BIOS (for compatibility) 
or to memory (for speed) * Graphics function help from CED editor 
* World, pixel or turtle color graphics modes * 47 standard fill 
patterns, 17 line dashing patterns, Hershey fonts, plus user 
defineable fill, dash, and fonts * Supports view areas, rotateable 
fonts, clipping, arbitrary fill areas, extensive error checking, 
examples, and user’s manual * Only $39.95 


M Eco-C88 Windowing Library 


Use this library to build pop-up windows, help windows, selection 
menus, special effects—anywhere you need an attention getter. 


Using a question-answer approach, this book is 
filled with shortcuts, tips, techniques, and traps to 
avoid*when learning C. Price is $17.00 plus $2.00 
for shipping. 


C Programmer’s Library 
(Purdum, Leslie, Stegemoller, Que Corp.) 


Another B. Dalton bestseller. An intermediate C 
text for the programmer that wants to get the most 
from the language. Contains source code for many 
functions including an ISAM file handler. Price is 
$22.00 plus $2.00 for shipping. 


* CGA and EGA support * Control any program that goes through 
the BIOS * Use up to 255 windows * No special window commands To order, call or write: 
— use plain old printf( ) to write to a window * Resize and move 

windows * Custom window titles and borders * Can be used with 1-800-952-0472 ss 1-3 17-255-6476 
ANSI device driver * Most window code-data are outside small model (for orders) (tech. info.) 

* User’s manual and examples for only $29.95 


HM Ecosoft Librarian 


Combine your modules, functions, and subroutines into your own 
library for easy link commands. Compatible with any standard 
MSDOS OBJ files * Add, delete, and extract from a library * Get 
table of contents or index of a library * Combine libraries, control 
library page size, use switches for combinations, process complex 
library requests, use wildcards, and do library directives from 
command files * Complete with user’s manual for only $29.95 


ORDER FORM CLIP & MAIL TO: 
Ecosoft Inc., 6413 N. College Ave., Indianapolis, IN 46220 


Eco-C88 C Compiler $59.95 

Eco-C88 Flexi-Graph Graphics Package $39.95 
Eco-C88 Windowing Library $29.95 

Ecosoft Librarian $29.95 

Developer's Library $25.00 ($50.00 if not with order) 
C Programming Guide $20.00 

C Self-Study Guide $17.00 

C Programmer’s Library $22.00 


HM Developer’s Library 


Contains the source code for for all library functions, including the 
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transcedentals, memfiles, and those written in assembler. $25.00 SHIPPING $4.00 
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ANSI C and 


Microcontrollers 


Microcontrollers are being used 
in more complex applications, 
increasing the need for high-level 
language software support. The 
architecture and use of stand-alone 
embedded microcontrollers, like the 
8-bit Intel 8051 family, differs from 
standard microprocessors like the 
8086. This article focuses on the 
special microcontroller considera- 
tions for an 8051 ANSI-Standard 
based C compiler. Topics include 
memory models, PROMmable code 
and other special features. 


C and Microcontrollers 


The advantages of programming 
microcontrollers in C are very 
much the traditional high-level 
language arguments — speed, 
ease-of-use, more reliable program- 
ming, debugging and code mainte- 
nance. However, the growing 
interest in C for microcontroller 
applications is also driven by other 
factors. As microcontrollers are 
increasingly used in more complex 
applications, large ‘‘chunks’’ of C- 
code can be ported from other 
architectures. Debugging is facili- 
tated, as generic C code may be run 
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and tested using host-resident com- 
pilers and debug tools supplement- 
ing traditional emulator debugging. 
Also, decreasing memory prices 
make it less important to squeeze in 
as much code as possible in every 
memory byte. 


A microcontroller is significant- 
ly different from a general-purpose 
microprocessor. The target system 
(i.e. the microcontroller) cannot 
support complex program develop- 
ment by itself. The code is com- 
piled and linked on a host machine, 
like an IBM PC or DEC VAX, and 
is downloaded through a serial port 
to an emulator, PROM program- 
mer, or the target system itself. 


Thus a C-compiler for a micro- 
controller demands more than one 
for a standard processor. The com- 
piler must generate code for an 
architecture with a constrained run- 
time environment. A  microcon- 
troller has on-chip memory and 
special (I/O-oriented) registers 
which have to be utilized effec- 
tively. The challenge is to provide 
the power of the full C language 
under these special constraints. 


The C-51 compiler described in 
this article conforms to_ the 
currently proposed ANSI Standard 
C language definition and has the 
important library functions imple- 
mented. The key design objective 
was to provide the full and efficient 
power of the C language coupled 
with optimal portability and with 
extra features to provide a time- 
saving development solution. 


The full C-51 kit consists of the 
C compiler with libraries, macro- 
assembler, linker, librarian and a 
special emulator converter utility. 


C was chosen over other high- 
level languages as C has low-level 
characteristics, it is a well-known 
systems implementation language 
and it is a well-defined language, 
therefore increasing code portabil- 
ity. 


The 8051 Architecture 


The MCS-51 8-bit microcon- 
troller family, developed by Intel, 
consists of the ‘‘8051’’ and newer 
proliferation chips like the 8052, 
8031, 8032, 8044 and 80452 (see 
Figures I and 2). The chip’s major 
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Figure 1: Program memory of the 8051 (core) microcontroller 
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Figure 2: Data memory of the 8051 (core) microcontroller 
(SFRs = Special Function Registers) 


features are: 


8-bit CPU. 


Resident 128 or 256 bytes of 
intemal RAM data memory 
(including general-purpose 
registers and a stack for func- 
tion and interrupt routine calls). 


Up to 64K bytes of external 
RAM data memory. 


Resident on-chip ROM/EPROM 
program memory (4K for 8051; 
8K for 8052; none for 803x 
chips). 


Expandable to 64K _ of 
ROM/EPROM program mem- 
Ory using external memory 
chips. 


8-bit stack pointer that can be 
set to any address in on-chip 
RAM. 


e 16-bit Program Counter giving 
direct access to 64K bytes of 
memory. 


e Several I/O lines, timers/count- 
ers, serial and parallel 1/O-ports 
(special function registers). 


e j11 machine instructions 
(including Boolean processor). 


e On-chip oscillator and clock cir- 
cuitry. 


The difference between the 
chips in the 8051 family is the 
amount of on-chip CODE and 
DATA memory and the number 
and functionality of special function 
registers and I/O ports. The C-51 
compiler supports all proliferation 
chips based on the 8051 family. 


Microcontrollers are used in 
applications ‘‘responding and con- 


trolling real-time events’’ versus 
microprocessors which are used to 
‘‘manipulate and process data’’. 
Typical microcontroller applications 
include 


instrumentation, process 
control, communication systems 
and peripherals. 
Ma ping from C to the 
80 


To best meet the requirements 
of different microcontroller designs, 
the C-51 compiler supports several 
hardware configurations, or memory 
models. (similar in concept to 8086 
small and large model). The dif- 
ferent C-51 memory models are: 


e Large reentrant and _ static 
memory model. Supports 
microcontroller applications 
with 64K of code and 64K of 
data. C variables and the ‘‘vir- 
tual’’ run-time stack reside in 
external data memory. 


e Medium reentrant and static 
memory model. Supports 
microcontroller applications 
with a combined total of 64K 
code and data. Requires 
ANDing two pins to create a 
uniform 64K _ address_ space. 
(This is required to avoid a 
conflict between the C run-time 
system needs and the [8051 
family | members] _ separate 
instructions for accessing exter- 
nal RAM and external or inter- 
nal ROM/EPROM). C variables 
and the ‘‘virtual’’ run-time 
stack reside in external data 
memory. 


e Small static (‘‘single-chip’’) 
memory model. Supports 8051 
configurations using only inter- 
nal RAM. C variables and the 
run-time stack reside within 
internal RAM. 


The reentrant model options 
fully support recursion. All auto 
variables are allocated and deallo- 
cated dynamically, i.e. they reside 
on the stack, which is necessary if 
recursive or complex interruptible 
functions are required. In the static 
option all function-level variables 
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are Statically allocated, except for- 
mal parameters which are always 
on stack. The static models produce 
somewhat faster and more compact 
code than the reentrant models. The 
small static model produces the 
most efficient code. 


The small model limits the way 
a C program can be written since 
the internal RAM is rather limited 
in the 8051 family. This means that 
auto variable space, recursion or 
extensive function call nesting must 
be used sparingly. Due to RAM 
limitations the C library functions 
Drintd, |-sprinct, <malioc 
and free are not available in the 
small model. However, the full C 
language is still applicable. [A 
free-standing ANSI-conforming 
compiler need not implement the 
full library as a hosted compiler 
must do. — Ed] 


Code density (i.e. size of gen- 
erated code) is the same for both 
large and medium memory models. 
However, in the ‘‘large’’ memory 
model initialized variables will take 
the same space from both the 
CODE and [extemal] DATA mem- 
ory. The initializer constants are 
stored in CODE memory and 
copied into the DATA memory at 
Start-up (completely transparent to 
the user). This also applies to C 
String literals. (This is because C 
variables are always accessed via 
MOVX instructions rather than 
through a mix of the 8051 MOVX 
and MOVC instructions. The latter 
would require inefficient 17-bit 
addresses in various routines). In 
the expanded large and medium 
memory models, C uses the internal 
RAM only for temporary storage 
(certain registers) and 20 bytes of 
stack. The registers hold temporary 
results for function return values for 
all data types. Two registers (R6 
and R7) contain a 16-bit ‘‘virtual’’ 
stack pointer and should not be 
modified. 


In the expanded modes parame- 
ters are pushed on the virtual stack 
in reverse order while the RETum 
address resides as the top element 
_ Of the internal stack. An assembly 
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routine is responsible for ‘‘pop- 
ping’’ all variables from the stack 
before returning to the caller. If the 
called routine has a fixed number of 
parameters this is straight-forward 
(e.g. if the function is called with 
two ‘int parameters it would pop 
four bytes from the stack). How- 
ever, a function being invoked with 
a varying number of parameters 
will be passed the size of the 
pushed parameter block in register 
DPTR. This is required so that 
registers R6, R7 are restored before 
returning. Immediately after a func- 
tion call the virtual stack in external 
RAM (in the expanded modes) 
appears as in Figure 3. 


The virtual stack grows from 
high to low addresses (contrary to 
the internal stack). To pop the vir- 
tual stack there are intrinsic 
libraries available which pop R3, 
R2-R3 and R2-RS. 


PROMmable Code 


PROMmable code is a must for 
microcontrollers. The compiler has 
a simple invocation option to gen- 
erate PROMmable code. The issue 
is the C language requirement that 
Static variables have a pre-defined 
value at program execution. The 
PROMmable code option solves 
this by generating two segments for 
each initialized static/external vari- 
able: one segment for the initializer 
values (constants), and one ‘‘sha- 
dow’’ segment for the variable 
itself. 


The initializers (usually residing 
in PROM) are transparently copied 


Startup routine. Static/external vari- 
ables without  initializers in 
PROMmable mode are put on a 
segment which is ‘‘zeroed’’ by the 
Start-up routine. This makes the 
program appear as if it has just 
been loaded from a disk to memory 
and then started to execute main, 
the C standard start function (see 
Figure 4). Another advantage of 
the PROMmable option is that a 
RAM resident program can be res- 
tarted and given identical results 
due to the automatic reinitialization 
of the static variables changed dur- 
ing execution. Strings are handled 
in a special way — using a com- 
mand line option strings can be 
defined either as “‘read-only’’ or as 
variables. 


Static variables must have a 
pre-defined value at program execu- 
tion. CODE is of course the execut- 
able code while UDATA contains 
the undefined variables, which in C 
equals zero. Variables which have 
been explicitly defined are ‘‘cut’’ 
into two equally large segments — 
IDATA contains ‘space for the vari- 
ables while CDATA contains the 
constants. At the start of the C pro- 
gram all code for the segment 
UDATA is zeroed and CDATA is 
copied into IDATA. 


Data Types and Type 
Checking of 


The C-51 compiler supports all 
basic proposed ANSI C elements. 
float, double and long 
double are all implemented in the 
IEEE 32-bit single precision format. 


to the ‘‘shadow’’ segment by the C Plain char is _ equivalent to 
low memory 
Argument 1 <—R6:R7 


Argument 2 


Argument n 


high memory 


DPTR contains the 
Size of the pushed 
parameter block 


Figure 3: The virtual stack (in the expanded modes) 
immediately after a function call. 
R6-R7 contain a 16-bit ‘‘virtual’’ stack-pointer. 


ROM/ PROM 


CODE 


CDATA 


2 


unsigned char in this imple- 
mentation but can be changed to 
signed char by a command line 
switch if needed. char, int, 


short and long can be signed or 
unsigned. The table below shows 
the size in bytes of the different 
objects. 


*The ANSI Standard requires a short 
integer to be able to represent at least the 
range of values -32767 to 32767, which in 
our environment, takes 2 bytes. To save 
critical memory space in a microcontroller 
application the user may assign a 1-byte 
short integer by using the C language 
pre-processing directive #define to set 


short int toa signed char. 


Variables are always stored with 
the most significant part located at 
the low memory address. In the 
expanded modes the R2 and R3 
registers hold return values for all 
types except long and float. 
Registers R2 through R5 hold func- 
tion return values for long and 
float. R2 always contain the 
most significant part. 


Structures, unions and arrays 
are supported as in any other C- 
compiler. Since each memory 
model specifies where C variables 
are stored, the compiler knows 
whether a pointer reference is made 
to internal or external memory. 


>.copied at start-up -— 


Figure 4 


The compiler performs 
advanced type checking. The built- 
in. ““strict’’ type check option does 
away with traditional tools like 
LINT without adding much compi- 
lation time overhead. The compiler 
checks a module whereas the linker 
checks consistency of inter-module 
declarations (down to the last bit of 
a complex structure). This facili- 
tates interfacing of libraries, or 
other routines only available in 
object format, as well as_ the 
integration of modules written by 
different programmers. 


ANSI currently supports 6- 
character external symbols due to 
“*historical reasons’’ (i.e. ANSI 
does not want to force imple- 
menters to write new linkers). How- 
ever, the C-51 package extends this 
limit to 255 characters. 


Run-time Considerations 


C-51 follows the latest ANSI 
X3J11 proposal when it comes to 
the language and implements a 
sub-set of the library (since 
fprintf and other types of func- 
tions do not apply to a free-standing 
microcontroller application). Exam- 
ples of library functions that are 
included are printf, malloc, 
getchar, putchar. 


Since the 8051 architecture does 
not mirror the C language com- 
pletely, the C-51 implementation 
requires a large set of support rou- 
tines as the code generator issues 
calls to ““helpers’’ when inline code 


zeroed at 


start-up 

ie at CLS 

“ int  j=2; 
I 


is too inefficient. These routines are 
split into some 100+ modules so an 
application’s C run-time system 
will only include those parts of the 
C language used by the program- 
Mer; .& 


A number of predefined routines 
can be enabled (as a compiler 
option) to facilitate the use of C in 
an 8051 environment. These rou- 
tines are recognized by the compiler 
which generates inline code for 
hardware dependent features like 
special function registers and bit 
variables (not the same as bit-fields 
which is a standard C feature). This 
makes it possible to write systems 
completely in C except when a very 
fast interrupt routine is needed. In 
the latter case an assembly language 
module (possibly linked with C 
code) is more appropriate. (Interrupt 
routines can be written in both 
assembly and C and the individual 
interrupts are implemented by the 
user modifying the C startup rou- 
tine.) 


If hardware must be initialized 
before the C program starts, code 
can be added to the C sStartup- 
routine (in assembly source) to do 
the hardware initialization. 


By default the run-time stack 
size is set to 64 and 512 bytes for 
the small single-chip and_ the 
expanded modes, respectively. The 
minimum usable stack size is 10-15 
bytes. 


By default the C-compiler 
optimizes the produced code on the 
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#1 C interpreter 


The professional 
C development 
environment 


Your C compiler creates great final code... 
but as a programming tool, its too,too slow. 
With C-terp you can edit, debug, and run 
without the wait. Nothing, but nothing, is faster 
for developing professional C programs. 


Choose the perfect C-terp companion 
for your C compiler 


C-terp/Microsoft C-terp/XENIX 
C-terp/Lattice C-terp/Aztec 
C-terp/Mark Williams C-terp/C86 


Link in all your compiler's functions, your own 
functions, add-on libraries, assembly routines, 
and data objects. Get instant access to every- 
thing in the C-terp interactive environment. 


Only C-terp offers all this and more 

# Full K&R with common ANSI 
enhancements 

= Source level interactive debugging 

= Software paging for your big jobs 

= Complete multi-module support 

= Run-time pointer checking 

= Unsurpassed reconfigurable screen 
editor 

= Dual display and full graphics support 

= Large model @ Call-in 


ORDER C-terp TODAY (specify compiler) 


C-terp runs on IBM PC, AT or 
compatibles. 

Price: 

MS-DOS 2.x and up - $298, 
Xenix System V 286-$498 
MC, VISA, COD matt 
30-day money-back 2 
GUARANTEE 


Trademarks: C-terp (Gimpel Software) 

C86 (Computer Innovations). Lattice(Lattice. Inc.). 
Xenix. Microsoft. MS-DOS (Microsoft. Inc ). Aztec (Manx 
Software). Mark Williams (Mark Williams Company) 

IBM (International Business Machines. Inc.) 


GIMPEL SOFTWARE 


3207 Hogarth Lane, Collegeville, PA 19426 
(215) 584-4261 
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C level. Two special optimization 
options are also available — “‘size’’ 
and “‘speed’’. In the size option the 
compiler makes external calls for 
everything except simple loads. The 
speed option produces more in-line 
code: 


ANSI Standard 
Enhancements 


The C-51 is a full implementa- 
tion of the proposed ANSI Standard 
C language. The proposed ANSI 
Standard is based on the traditional 
Kernighan & Ritchie definition of 
the C_ language, with certain 
enhancements. 


Function prototyping allows 
function declarations a la Pascal 
with the conversion conventions of 
C. This speeds up software 
development and may help in pro- 
ducing more efficient code by 
avoiding some of the default 
conversions to int that is required 
by the previous language definition. 
Structure and union assign and 
enum types give the C programmer 
the same facilities enjoyed by Pas- 
cal users. auto initialized aggre- 
gates like arrays, structures and 
unions allow more flexibility by 
giving one more option to keep 
vital data local to a function rather 
than making everything global. 


The ANSI Standard will further 
standardize the C language, increase 
its portability and ensure that C will 
not run into the same problem of 
incompatible dialects as did, for 
instance, Pascal. 


Host Requirements 


The C-51 compiler takes advan- 
tage of the increased memory space 
available in today’s host systems 
and requires 512K bytes of RAM 
on an IBM PC. The compiler itself 
is one single program and all data 
created during compilation resides 
in RAM. This results in fast compi- 
lations. Another is its simplicity, 
e.g. memory objects are much 
easier to manipulate and access than 
if stored in temporary files. A draw- 
back is that the compiler cannot be 


ported to a memory-limited archi- 
tectures like the PDP-11. The C-51 
compiler is currently available on 
the IBM PC and compatibles, VAX 
and MicroVAX (UNIX and VMS). 


Miscellaneous Points 


The relocatable code is gen- 
erated in one pass. For debugging 
purposes there is an option to pro- 
duce a list of C code mixed with 
symbolic machine code. Paginated, 
line numbered list files as well as 
cross-references for functions, vari- 
ables or macros are produced while 
compiling. 


Standard mathematical support 
like trigonometric, exponential and 
logarithmic functions is included. 


Concluding Remarks 


When does it make sense to use 
C for a microcontroller application? 
In a high-volume simple 
consumer-type of product, the 
cost-savings in memory chips usu- 
ally offset the extra [development 
time] costs of using assembly 
language. On the other hand a low 
volume instrument, where com- 
ponent cost is only a fraction of the 
total system cost, the high-level 
language C choice is more 
appropriate. Newer microcontrollers 
like the Intel 8096 are programm- 
able in C almost equally well as in 
assembler which makes _ the 
language decision even simpler. 
The described microcontroller C 
compiler technology is currently 
being ported to other architectures. 
C is likely to become the ‘‘assem- 
bly language’’ of the future while 
more application-specific languages 
will proliferate in high-end applica- 
tions. 
[Anders Gezelius, Daniel Lau and 
Anders Rundgren are senior soft- 
ware engineers with Archimedes 
Software, Inc. (San Francisco, CA), 
Intel Corp. (Santa Clara, CA), and 
IAR Systems AB (Uppsala, Sweden), 
respectively. Lau is _ Intel's 
representative on the ANSI X3J11 
Committee and Rundgren is a fre- 
quent contributor to the ANSI Stan- 
dards process.] 


Authoritative C Expertise 
from Plum Hall: 

Training, Books, and the 
Plum Hall Validation Suite 


Organizations seeking impartial C 
expertise have turned to Plum Hall 
since 1979. C Workshops, Intro- 
ductory and Advanced, are available 
both in-house and on a regular public 
schedule. Plum Hall textbooks con- 
stitute the most comprehensive in- 
tegrated series on the C Language. 


The new Plum Hall Validation 
Suite is alarge set of C programs for 
testing and evaluating C compilers 
and interpreters. The Suite provides 
compiler writers a cost-effective 
distillation of the validation and testing 
experience of several projects. And 
for the user organization confronting 
important compiler-product selec- 
tions, the Suite is an effective tool for 
detailed feature-by-feature compiler 
comparisons. 


The Plum Hall Validation Suite is 
tracking the development of the ANSI 
C Standard. Each “shall,” ‘shall 
not,’ constraint, and syntax rule of 
the Standard will be tested in the 
Suite. Over 22,000 lines of carefully 
written C, plus over a million bytes of 
Script generated C, provide compre- 
hensive coverage. 


Plum Hall at your service 

For fast next-day shipment of book 
orders, for information about top- 
quality training, and for details about 
the Plum Hall Validation Suite, call 


Joan Hall 
President 

Plum Hall Inc 

| Spruce Avenue 
Cardiff NJ 08232 
609-927-3770 
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Practical Yacc 
— Part 1 


The myth of yacc 


As the folk tales of computer- 
dom get told and retold, some of 
the fabled characters and _ their 
accomplishments merge into ever 
crisper focus. One of the enchanted 
settings for these fables was Bell 
Labs, and one of the magical times 
was long ago when the UNIX 
Operating system was invented out 
of nothingness. And we all know 
that along with the UNIX operating 
system came a dazzling array of 
tools that sparkled and did magical 
feats that could scarce be believed. 


Prominent among these tools 
was yacc, Spirited into being by 
one Stephen Johnson, who, accord- 
ing to his chroniclers, admitted 
being pressed by others ‘‘beyond 
my inclination, and _ frequently 
beyond my ability, in their endless 
search for ’one more feature’.’’ 


From that enchanted setting, 
yacc wended onto mainframes 
throughout the entire world, into 
the DECUS domain, whence it 
passed into the individual domains 
of personal computer users every- 
where, and in its own particular 
way it reigns securely in all these 
domains to this very day. 
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Dennis Deloria 
MOBIUS Corporation 


And the footnote to this fable, 
repeated in every book assaying its 
magic, is its whimsical name — 
Yet Another Compiler Compiler. 


Ah, the stuff of fables! Once 
casual readers get to the ‘‘compiler 
compiler’ part, their eyes glaze just 
a wee bit, and most put down the 
quaint story about this strange tool 
from ancient UNIX times. They 
turn their minds back to their press- 
ing daily tasks, due by the end of 
the day. Too few realize this yacc 
thing just might help them reach 
their day’s objectives. 


So what is yacc, anyway? 


Modern chroniclers have more 
or less agreed to call yacc a ‘*parser 
generator’ instead of a ‘‘compiler 
compiler.’’ For the uninitiated, this 
is at best a trivial improvement. 
Parser generators can be considered 
as a subclass of the larger class 
known as ‘“‘program generators’’. 
As we know, a program generator 
uses some abbreviated input to gen- 
erate the source code for a much 
larger program in some _ other 
language, thereby saving the author 
much work. 


Yacc specializes in generating 
programs that parse input streams 
into meaningful instructions for 
larger, more general purpose pro- 
grams. The input to yacc is a 
“‘language specification’’ which is 
expressed in an easily managed for- 
mat (known as Backus-Naur Form, 
or more simply, BNF). Examples of 
languages expressed in Backus- 
Naur Form are plentiful and easily 
found throughout contemporary 
computer publications. The format 
allows great freedom to authors for 
inventing practically any type of 
language they might need for their 
purpose. 


While the input to yacc is some 
kind of language specification, the 
Output is straight C source code. 
Well..., almost. Because of the 
Symbol table algorithms imple- 
mented in yacc, the output C source 
code looks cryptic at best, but it 
will compile and run correctly on 
most standard C compilers. 


Embedded throughout the yacc 
Output source code is the author’s 
very own code, to carry out the pur- 
poses of his or her end program. 
Brave authors can hack the yacc 
Output at will before compiling it. 
We timorous will modify our 


C spoken here... Pascal spoken here... 


' be : ™ 
High C Professional Pascal 
Do you want to use a C compiler that Do you want to use a Pascal compiler that 
e was chosen by Ashton-Tate for dBASE III® Plus, and e was chosen by Lifetree Software, Inc., for implementing 
CAD Leader AutoDesk for AUTOCAD and AUTOSKETCH Volkswriter Deluxe™ 
“with a twenty percent code savings over Lattice C.”’ e serves as a systems and applications language at 
e was well rated in Computer Language, Feb. 86: CAD/CAM giant Daisy Systems Corporation 
“Then there is High C, the most powerful compiler of all...’ © was well rated in Computer Language, May 86: “The 
and Dr. Dobbs Journal, August 86 clear choice for large-scale programming projects...’’; 
e “would have saved me three weeks of porting time had | and PC Tech Journal, July 86: ‘‘for team programming 
had High C instead of Microsoft's new C” or for very large projects...stands absolutely alone.”’ 
Mike LeBlanc, compiler developer, Sky Computers pg. 126 ‘‘documentation is certainly the best...a model of 
e “is the only C compiler for the IBM PC capable of com- technical clarity.” pg. 112. 
piling NYU’s Ada/Ed compiler’ e is the ‘howitzer’ of Pascals and ‘“‘could well be the most 
Dave Shields, research scientist, New York Univ. powerful Pascal compiler ever implemented on a 
e has a complete run-time library microcomputer’’ PC Magazine, Oct. 29, 1985, p. 144 
e has structure assignment, enum, void... e has 8-, 16-, and 32-bit integers; sets up to 64K bits 
e supports nested functions as in Pascal e has varying-strings of up to 64K characters 
e supports pcc and full K&R C plus some latest, nifty ex- e has a full-fledged C macro preprocessor 
tensions from the new ANSI-proposed C standard e has many run-time library additions: UNIX™-like I/O, multi- 
e “is the highest quality C compiler for large-scale software ple heaps, interrupts,. . . 
development.” Randy Nielsen, Ansa (Paradox) e has all the bit-pushing operators of C 
e ‘‘saved 15% of code over five large modules of MultiMate ¢ has many more extensions, getting you half way to Ada® 
relative to Lattice C”’ for a non-Ada price 


David Beauchesne, Multimate International 


Power Tools mt Power Users 


Each compiler ¢ generates superb code, with optimizations such as common-subexpression elimination and cross-jumping ® sports 
no less than five memory models for the 8086 (Small, Compact, Medium, Big, and Large) ¢ supports a unique implementation of register 
variables © supports the 8087/80287 in native mode, or emulates ¢ supplies three floating-point formats ¢ generates special instructions 
for the 80186/286 © generates code that runs in 80286 protected mode ¢ gives you hundreds of error and warning messages, help- 
ing you find those subtle bugs before you need a debugger’s help ¢ lets you overlay data as well as code (when used with PLINK86), 
for substantial space savings ¢ lets you write interrupt routines directly in high-level language ® lets you get ‘‘close to the machine”’ 
with built-in move/scan/compare operations ¢ is supported by equivalent resident and cross compilers for the 80286 (UNIX V.2, Xenix, 
Concurrent DOS 286), 80386 (DOS, UNIX V.3), 68010/20/68881 (UNIX V & 4.2, GEM-DOS™), 32032 (UNIX 4.2), VAX (UNIX 4.2, 
VMS), RT PC, IBM 370,... © contains a multi-modular cross-referencer ¢ produces ROM-able code for embedded applications 
¢ can talk to those other languages by those other vendors ¢ gives you 64K run-time stack space that can be shared with 
the heap ¢ is endowed with an amazing number of pragmas (compiler controls) for customization to your application ¢ has 
a compiler start-up profile * supports direct access to MS-DOS; library supports DOS 3.X file-sharing * generates symbolic debugger 
information for use with all Known MS-DOS debuggers ¢ allows exec-ing subprocesses ® was designed for professional software 
developers, not hobbyists ¢ comes with great technical support by a company that specializes in compilers ¢ comes with exten- 
sive typeset documentation ¢ and more... call or write for your information packet today... 


Not recommended for casual use, but for applications needing industrial-strength tools, contact 


Abroad: 

ABC Software, The Netherlands 
Microsoftware, Tokyo 

Grey Matter, United Kingdom 


INCORPORATED Buchdata, Frankfurt 


903 Pacific Avenue, Suite 201, Santa Cruz, CA 95060-4429 
(408) 429-6382 (429-META), TELEX: 493-0879 


Professional Tools Since 1979 


High C V1.3: $495 —on any MS/PC-DOS system— Professional Pascal V2.6: $595 
OEMs: Contact us about porting our professional compilers to your systems. 
TWS: Professional Compiler Developers and competitors, ask about our Translator Writing 


System compiler toolbox; see the review in Computer Language, December, 1985. 
DOS Helper™: Powerful UNIX-like utilities to enhance MS-DOS, for $49.95—included free with 
MetaWare compilers: FIND, TAIL, MV, LS, CAT, UNIQ, FGREP, and WC. 
C Validation Suite: Used by some of our competitors and many others. $2,000/Plant Site 


e MetaWare, High C, Professional Pascal, and DOS Helper are trademarks of MetaWare Incorporated ¢ Other trademarks and their owners are: UNIX—AT&T, dBASE 
\II—Ashton-Tate, Volkswriter Deluxe—Lifetree Software, GEM-DOS—Digital Research, Ada-DoD. © 1986 MetaWare Incorporated. 


wr Circle 119 on Reader Service Card-= 39 e THE C JOURNAL 


language specification and pass it 
through yacc again, leaving the out- 
put pristine and much less error- 
prone. 


How do we benefit by 
using yacc? 


Every program we write accepts 
input commands in some format for 
specifying what we want the pro- 
gram to accomplish. In many of 
today’s programs the input com- 
mands border on the Byzantine in 
complexity, and hand-coding all 
possible permutations becomes a 
nightmarish challenge. Yacc can 
help reduce the challenge to human 
proportions, even for complex pro- 
grams. 


One frequently hears debates 
about the merits of menu-driven 
user interfaces compared _ to 
command-driven user interfaces. A 
solid consensus is emerging that 
menus are helpful to novice users, 
but become an increasing hindrance 
as uSers gain experience. Best con- 
temporary practice encourages both 
interfaces within the same program, 
allowing users to migrate from 
menus to commands at their own 
speed. Yacc can make it practical to 
add snappy and coherent 
command-driven interfaces to 
almost any of your programs. 
Moreover, these interfaces will be 
largely error-free since yacc will 
assist you in debugging your com- 
mand language specification. 


A more subtle point is that yacc 
can help you move to a clearer 
understanding that what you are 
actually doing is ‘“‘developing a 
language’’ for users of your pro- 
gram, rather than ‘‘writing a pro- 
gram.’’ As you address the issues 
of defining that language, you make 
access to your program easier and 
smooth out discontinuities that pro- 
voke unpleasant responses from 
your users. Moreover, as you 
achieve a clearer understanding of 
future directions for your program, 
you can implement evolutionary 
enhancements in the command 
language with little effort, and 
without disrupting established parts 
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of the command language. Jon 
Bentley, in his August 1986 Pro- 
gramming Pearls column in the 
Communications of the ACM, looks 
at some of the methods for develop- 
ing what he calls ‘little 
languages’’, and the benefits pro- 
grammers can achieve by exploiting 
linguistic insights in developing 
user interfaces for their programs. 


Yacc is designed to put few res- 
trictions on its users. The language 
specification input to yacc is very 
flexible, allowing great expressive- 
ness in a wide variety of applica- 
tions. Authors can modify both the 
input and output, and freely inter- 
mix their own code either in yacc, 
or in lex (a companion program 
generator frequently used with 
yacc), or in the action portions of 
their application programs. 


As a carefully conceived, dedi- 
cated tool, yacc is small and rela- 
tively easy to learn. It works well 
with many other tools, in the classic 
UNIX operating system tradition. 
Yacc output is quite reliable, since 
it is based on a tight mathematical 
model. The algorithms involved 
permit the generation of fast, com- 
pact, error-free code, well within 
production standards. It is usable 
with standard C compilers, and the 
generated source code is highly 
portable. 


In short, yacc lives up to its 
legend. 


What can we build with 
yacc? 


The list of practical programs 
created with yacc’s help is impres- 
sive. At the high end are compilers 
for C, APL, Pascal, FORTRAN 77, 
and RATFOR. Implementation of 
the Portable C Compiler (PCC) and 
Lint were assisted by yacc. 


Less conventional languages 
that have been implemented using 
yacc include the UNIX stalwarts 
awk (a pattern scanning and pro- 
cessing language), bc (interactive 
desk calculator), eqn (mathematical 
typesetting preprocessor for troff), 


and pic (a line drawing language 
for troff). 


You may feel somewhat awed, 
like I do, by this imposing collec- 
tion. Moreover, these examples 
come straight from the UNIX 
Operating system documentation 
sources and do not reflect any of 
the hundreds of other yacc applica- 
tions that surely exist. 


My own ambitions for yacc are 
more modest. One use that I envi- 
sion is adding littke command 
languages to some of my database 
application programs, which are 
now primarily menu-driven. 
Another possible quick-and-dirty 
use is generating command drivers 
for testing functions during the 
development process. 


A second use that seems 
promising to me is in the area of 
language translators. Currently I use 
the KMAN procedural language for 
writing some of my database appli- 
cation programs, but as I add more 
and more features the speed and 
functional limitations of parts of the 
interpreted KMAN language 
become substantial barriers. I like 
prototyping with KMAN, however, 
so rather than abandon it I hope to 
write a language translator that 
takes KMAN procedural language 
as input and generates source code 
output that interfaces directly to a C 
language screen-handling system I 
wrote, and db_vista, a powerful 
commercially-available C database 
management system (which itself 
was written with yacc’s help). 
With yacc it seems reasonable to 
generate source code output that 
uses the exact collection of home 
grown and commercial functions I 
incorporate into my programs at 
any given time. Without yacc I 
could not hope to write such a tool. 


A third, related application that 
has occurred to me is a small trans- 
lator for converting into the C 
language some of those nifty little 
Turbo Pascal programs that are 
turning up everywhere. 


Some candidate projects have 
been left off my list solely because 


I already have perfectly acceptable 
programs written by others that do 
the same tasks. These include 
pretty-printers, batch editors, and 
macroO-preprocessors. 


I already “‘wrote’’ a series of 
programs that were never in my 
plans, and you might very possibly 
‘‘write’’ them as well. These were 
a series of calculators, from a very 
simple one to a surprisingly power- 
ful one (comparable in power to the 
BASIC language). These calcula- 
tors were used as program develop- 
ment exercisers for learning yacc by 
Brian W. Kernighan and Rob Pike 
in their book The UNIX Program- 
ming Environment (Prentice-Hall, 
1984). Their book first made yacc 
accessible to me, and will most 
likely be your own passport to it 
should you choose to incorporate 
yacc into your workaday toolkit. 
Not only was it a superb way to 
learn, but I ended up with a useful 
calculator for my personal com- 
puter, free. I’ll retum to Kemighan 
and Pike (K&P) shortly. 


The last application I’ll mention 
here is one we’ll do together as part 
of the tutorial. Have you ever 
wished for a cross-referencing util- 
ity that could examine your source 
code, with all of the #included 
files, and could identify exactly 
where and how each variable or 
function is declared? Some of the 
eight or so xref utilities that I now 
have list every line number where a 
variable is used, but not where and 
how it is declared. Others show 
function declarations, but not vari- 
able declarations, and not for 
#included files. An example pro- 
ject like this would not only pro- 
vide a useful learning vehicle, but 
would yield a useful tool at the end 
to assist our programming. 


What you will need 


Before we embark on our little 
project, you will need to assemble a 
few materials. 


A tutorial on yacc is not very 
practical without yacc itself, of 
course. If you plan to use an IBM- 


PC (or compatible), as I did, there 
are two. nationally advertised 
sources where you can get a work- 
ing public domain copy of yacc 
inexpensively. 


One source is the Austin Code 
Works, 11100 Leafwood Lane, 
Austin, Texas 78750 (512) 258- 
0785. The cost is $25 for a small 
model version of yacc (and a ver- 
sion of prep) with executable and 
source code, $35 for large model. 
Lex is also available for an addi- 
tional $25 for the small model, or 
$35 for the large model. The per- 
son behind the Austin Code Works 
is Scott Guthery, who converted the 
DECUS version of yacc for the 
DeSmet C compiler on the IBM- 
PC. The large model yacc is a 
recently cleaned up version where 
all the ints used as pointers have 
been changed to actual pointers, so 
it can be correctly compiled with 
intermediate and large models. 


The second source is the C 
Users’ Group, PO Box 97, McPher- 
son, Kansas 67460 (316) 241-1065. 
The C Users’ Group credited their 
version of yacc to Guthery as well, 
but they apparently did not get it 
directly from him. The CUG pro- 
vides only the small model version, 
at a cost of $16 for yacc and prep 
(disks #174 and #175), and $16 for 
lex (disks #172 and #173). If you 
are working on a non-IBM personal 
computer, the CUG can provide the 
yacc source code in over 200 disk 
formats, which you can then modify 
and recompile for your own 
environment. 


If you are now using the UNIX 
Operating system on a_ personal 
computer, you may already have 
access to yacc, depending on the 
completeness of the implementa- 
tion. If you are using the UNIX 
Operating system on a_larger 
machine, you most likely do. 
Check the system documentation 
for access. 


Next you'll need a good C com- 
piler. Depending on the project I 
am working on, and the compiler 
required by the functions I use with 
it, I may use either the CI-C86 
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compiler, the Microsoft C compiler, 
or the Lattice C compiler. For com- 
piling the calculator programs from 
K&Pike I prefer the Microsoft com- 
piler (particularly version 4) 
because it implements the floating 
point exception handler SIGFPE 
closer to the UNIX method used in 
the K&P text than do the CI-C86 
and Lattice compilers. The Austin 
Codeworks yacc with the Microsoft 
compiler permitted use of the exact 
K&P code in most places. 


You will also need some 
dependable written guides for this 
tour of yacc. First and foremost, 
get a copy of The UNIX Program- 
ming Environment. I guarantee it 
will be one of the better bargains 
you’ve made during your program- 
ming career. The last third of the 
book is devoted more or less 
exclusively to the topic of program 
development using yacc. It pro- 
vided me one of the most enjoyable 
and instructive programming 
experiences I have encountered 
since Software Tools, another clas- 
sic book from Kernighan, in colla- 
boration with P J. Plauger. 


Kemighan and Pike begin their 
exploration of yacc by implement- 
ing a very simple ‘“‘high order cal- 
culator’’ (hoc), which requires only 
59 lines of input to yacc. For jump- 
ing right in this is an ideal project: 
the code is so straightforward that 
the required pieces and their inter- 
connections become immediately 
visible. Since there are a few small 
but nonstandard quirks in the yacc 
implementation, and some differ- 
ences to contend with between PC- 
DOS and the UNIX operating sys- 
tem, they can be discovered and 
mastered here, before embarking on 
the more advanced versions of hoc. 


The second version of hoc 
involves 94 lines of yacc input, and 
adds variables with names a 
through z, and some minimal error 
checking to the bare bones calcula- 
tor. The third version, with 248 
lines, adds arbitrarily long variable 
names, many built-in functions, and 
some useful constants. 


Between the third and fourth 


versions a fascinating transforma- 
tion takes place. Both versions per- 
form identical tasks, but where the 
third uses conventional functions to 
implement actions for each com- 
mand, the fourth version creates a 
stack machine to implement them 
through an interpreter. This is in 
preparation for the vastly increased 
power of versions five and six. As 
might be expected, version four is 
much larger, with 396 lines of code. 


Beginning with version five we 
can see a true programming 
language emerge from our efforts. 
It implements if-else and while 
Statements like those in C, state- 
ment grouping using braces, and 
relational and logical operators. The 
number of lines of intermixed yacc 
and C code is now up to 574. 


In the sixth and final version, 
recursive functions and procedures 
using arguments are added, and 
Statements for input and output of 
Strings as well as numbers. The 
One-stack machine is augmented 
with a second stack to keep track of 
nested function and procedure calls. 
By this time we have watched the 
calculator grow from 59 lines of 
code to 809, and witnessed a 
remarkable functionality increase. 
We are now brimming with ideas of 
our Own to implement, and reason- 
ably well trained to implement 
them. 


If you decide to get started on 
your own using K&P, and I heartily 
encourage you to, a few hints might 
Save you a little trouble. In the 
notes accompanying yacc it is 
pointed out that yylval (a vari- 
able used to communicate between 
modules) is declared extern in 
the source code output from yacc. 
All of the K&P code assumes this 
to be the lvalue declaration, so the 
word extern must be hand edited 
out of the yacc output each time. 


Next, if your compiler does not 
Support union assignment you will 
need to provide a function in your 
code for hoc3 to do so. This one- 
line function found in the yacc 
source code will do just fine: 


yyunion(to, from) 
YYSTYPE 40, *Erom; 
{ 

to->val = from->val; 
j 


The referenced union member 
val is defined in the hoc3 header 
files given in K&P, and needs to be 
later changed to sym for hoc4, etc. 


Another slight modification 
required for hoc3 is in the naming 
of some of the added functions. 
K&P simply capitalize the first 
letter of some function names to 
distinguish between the standard 
library versions and their error- 
trapped counterparts, but the DOS 
linker is not case sensitive so it 
appears to set up an infinitely recur- 
sive loop and pops the stack. Sim- 
ply double the first letter in these 
names instead of capitalizing them 
and you’ll avoid the problem. 


The floating point exception trap- 
ping will be a sticky problem if 
your compiler does not have provi- 
sions for it. The simplest fix may 
be to leave out this error handling. 
The. proposed ANSI X3J11 C Stan- 
dard includes signal() and 
SIGFPE, so within the near future 
many additional compilers should 
support the exact code given in 
K&P. 


If you get stumped in the later ver- 
sions of hoc you can cheat and look 
at the full version of the final code 
from the appendix. 


In the next part of this tutorial we 
will look at some more written 
documentation you might want to 
have, examine the structure of a 
yacc program, go over the steps in 
using yacc, and begin preparing the 
specifications for our cross refer- 
ence utility. 


[Dennis Deloria is a partner in 
MOBIUS Corporation in Northern 
Virginia. He writes on-line tele- 
phone interviewing systems in C, 
and custom database management 
systems for many applications in C 


and KMAN, all for personal com- 
puters.] 


CI-C86 is a trademark of Computer 
Innovations 

KMAN is a trademark of MDBS 
Turbo Pascal is a trademark of Bor- 
land International 


Here’s atip... 
a Tax Tip. 


Don’t Pass up the opportunity to 
get free information on 
numerous tax subjects. IRS has 
over 100 special publications to 
answer tax questions. In fact, 


Pub. 910, “Guide to Free Tax 
Services,’ describes all of the 
free tax services available. Call 
1-800-424-FORM (3676) or the 
IRS Tax Forms number in your 
phone book to get a copy. 


= —_ 

= — —S 

— 

oe 

———_— 
———— 
———— 


A Public Service of the IRS 


Complete C Programs 
in Half the Time, 
with Instant-C™ 


Instant-C helps you create a working, well-tested program faster than 
any other interactive C development system. Much faster than traditional 
compilers, linkers, and debuggers. 


Hx: to believe? Here’s how we do it. 
Because Instant-C is a high-per- 
formance interpreter there are no com- 
pile or link delays. Change your program, 
then test it immediately. No matter how 
large your program, the turnaround time 
is just seconds. 


“Instant-C means instant gratification.’ —PC 
Magazine, Editor’s Choice for best C interpreter. 
10/29/85 


“Time after time, the Instant-C prompt was 
starting back just barely after pressing Enter” — 
PC Tech Journal, 5/86 


Source-level debugging saves your time. 
- set any number of conditional 
breakpoints in your program; 
- stop execution from keyboard; 
- single-step by source statement; 


- examine and change variables or 
code, and continue execution; 


- execute any statement or function 
directly for instant testing; 


- display source code back-traces; 
New!- source code animation; 
New!- monitor data changes; 


New! - full-screen and multi-screen support, 
even with non-standard graphics 
devices. 


“The resulting debugging and testing 
capabilities are fantastic and the detailed 
trace/debug/display commands make it easy. — 
The C Journal, 5/85 


Run-time checking stops your program 
as soon as errors occur, when bugs are 
easiest to understand and fix. 


New! - pointer references checked for 
reasonableness; 


New!- array indexes checked within 
declared bounds. 


Not only does Jnstant-C help you quickly 
change, test, check and debug your code, 
but it runs your program faster than any 
other C interpreter. Fifty to 500 times 
faster! Fast enough for real programs, 
even fast enough for real-time programs. 
“It is much faster than any of the other products _ 

mentioned and was the only one able to 

complete the standard SIEVE in a reasonable 

time. Clearly, this high speed allows much more 

complex problems to be attacked with Instant-C 

than with any of the other products 

discussed.” — Computer Language, 2/86 
Immediate feedback and more than 400 
diagnostics makes /nstant-C great for 
learning C. Full K&R and the ability to New! 
link compiled object code and libraries 
(Lattice and Microsoft) makes Jnstant-C 
compatible with your existing programs.New! 
~ “When you get right down to it, [don't think 

there's a better way you could learn C.’— 

Programmer's Journal, 3/85 

“Clearly, Instant-C is the performance 

champion.’ —PC Tech Journal, 5/86 i. 


The bottom line for your business is in- 

creased productivity. The result for you is 

a job well done, and quickly. 
“We sincerely feel that Instant-C can have a 
major positive impact on programmer 
productivity. —Computer Language, 2/85 
“Instant-C by Rational Systems is a C 
programmer's dream.’ —Micro/Systems Journal, 
3/86 


Version 2 is available for MS-DOS and 
PC-DOS, and comes with a full 31 day 
money back guarantee. /nstant-C is only 
$495. Order today! Call or write for full 
information. 


Rational 20.80.4890 


Natick, MA 01760 
Systems, Inc. (617) 653-6194 


ar Circle 116 on Reader Service Card-= 


A3 e¢THE C JOURNAL 


Sam Harbison is Director of C 
and Modula-2 products with Tartan 
Laboratories in Pittsburgh, PA. He 
studied Mathematics at Princeton 
and completed a Ph.D. in Computer 
Science at Carnegie-Mellon. Most 
of his research has been in the 
areas of operating systems and 
multi-processors with some com- 
puter language and_ compiler 
research. His dissertation covered 
optimizing compilers and computer 
architecture. 


The C Journal: The book C: 
A Reference Manual you wrote 
with Guy Steele is certainly one of 
the most popular C texts. How did 
that come about? 


Sam Harbison: After about a 
year of research, Tartan Labs 
decided to start its first compiler 
product. There was a lot of discus- 
sion on what language it should be 
and finally we chose C. Initially, I 
took on the C compiler project by 
myself and sturted working on the 
front end. Then Guy Steele joined 
the company and came into the pro- 
ject. 


As it happened, neither of us 
had had a whole lot of C program- 
ming background. Guy is known 
mostly for his Lisp work and I had 
been programming most recently in 
Bliss and an internally developed 
Tartan language. So we sat down 
and tried to learn C so we could 
define what the compiler would 
have to do. We found that we 
couldn’t quite decide from the 
books. There were certain very grey 
areas of the language. And so we 
began setting all these things down 
and deciding for ourselves what the 
language meant. 
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I had heard that Prentice-Hall 
might be interested in a book with a 
more modern treatment of C than 
K&R. This was in 1983-84 before 
the great wave of C books hit, so it 
seemed like a good fit. Anyway, we 
needed a book to ship with our 
compiler. At the same time Guy 
and I were just beginning to partici- 
pate in the ANSI Standards effort 
and for some time there was a little 
confusion about what version of C 
we were going to be describing in 
the book. However, we decided to 
describe the modern, common prac- 
tice of C and did not speak about 
the ANSI efforts in the first edition, 
or about any specific extensions 
that Tartan Labs put in their com- 
piler. 


CJ: To talk about common 
practice means getting some experi- 
ence in several environments. How 
did you go about doing that? 


Harbison: While we had both 
used C, mostly in a UNIX environ- 
ment on DEC machines, it was cer- 
tainly not our most used language. 
Doing the first compiler (for a DEC 
VAX running the UNIX system) 
we had occasion to look at an awful 
lot of C code and in getting the 
compiler up and compiling the 
UNIX system itself, our attention 
was drawn to particular C program- 
ming styles. A certain amount of 
Style can simply be inferred from 
the language itself. Certain idioms 
arise and the common ones you see 
very quickly in C programming 
either in the books or in code. 


CJ: One particular strength of 
your book is the considerable treat- 
ment given to the library. Where 
did you get the definition of the 


library from? 


Harbison: A lot of the credit 
for that goes to Guy. Frankly, we 
took explanations that other people 
had and in most cases they were a 
little vague too, so we ended up 
reading a lot of code. We had BSD 
and System V sources and descrip- 
tions of the library done for PC 
implementations. For a lot of it we 
simply (Guy especially in the I/O 
library) sat down and read the code 
that implemented them and found 
the boundary cases that were not 
well specified or handled and we 
mentioned those in the book. The 
Specifics of printf are an exam- 
yle. I’m not sure we have hit all of 
them yet but we are getting better at 
it though. After ANSI C was 
further along, we chose their run- 
time library as the standard and 
tried to explain it clearly. 


CJ: I have heard a lot of com- 
ments about the problems with 
Appendix A of K&R. Is there any- 
thing specific that comes to mind 
why that is not an appropriate book 
for implementers? 


Harbison: It is still a good 
book for beginning with C. Since 
they didn’t exist, and the book has 
not been revised, it does not men- 
tion the more modern features of C 
such as structure assignment and 
argument passing and the void 
function type. In some cases. it 
mentions some obsolete features, 
but it recognizes that they are 
obsolete so it isn’t a real failing. 


There are several areas having 
to do with some of the arithmetic 
operators or some of the. functions 
that ignore certain boundary condi- 


tions. What happens if you give a 
negative shift count to one of the 
shift operators, or you are required 
to do a signed left or right shift? 
Things like that were occasionally 
missing from the book. Some of the 
arithmetic seemed to assume two’s 
complement operations fairly often 
and I think there were many cases 
we found out of doing the compiler 
that while the particular statement 
of a language feature was correct, 
the implications of that do not seem 
to have been exposed very well. 
And there seemed to be some ques- 
tion about what the implications 
could be because the obvious impli- 
cation would seem counter to the 
spirit of C. 


CJ: So the definition in K&R 
shows its history in terms of the 
PDP-11 environment. 


Harbison: I think much of C 
shows its origins — from the auto 
increment and decrement instruc- 
tions on down. 
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CJ: Was it intended that your 
book be something «that other 
implementers could work from? 


| think much of C shows 
its origins 


Harbison: When we finished 
the first edition we thought that 
showing a ‘‘sanitized’’ version of 
Our actual product grammar would 
be a good idea. A lot of the gram- 
mars for C were YACC style gram- 
mars and YACC is a bit forgiving 
at times about LALR(1) grammars 
whereas Tartan’s parser generator is 
not. So we were forced to generate 
a strictly LALR(1) grammar for C 
and we thought that it would be a 
useful thing to publish. Judging 
from the responses we got, there 
seemed to be a lot of people who 
actually tried to take that grammar 


Software 


and put it through their favorite 
parser generator. 


CJ: Could you comment on 
the grammar used in the proposed 
ANSI Standard. 


Harbison: I think the grammar 
is better than the C community has 
had. In certain areas, expressions 
for instance, the precedence is 
expressed in the grammar now so 
that bit of ambiguity has gone. You 
don’t need to have a notion of pre- 
cedence aside from the particular 
grammar. I think the form of the 
grammar we used in the first edi- 
tion, which was derived from the 
notation we used in our parser gen- 
erator, was probably a bit obscure. 
In the second edition of the book 
we use the conventional presenta- 
tion for C grammars. In some sense 
that is a retreat. 


CJ: How much of a problem is 
there in trying to define a language 
standard using English? 
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Harbison: Syntactically I think 
the ANSI Committee has been pre- 
cise enough. Their grammar is not 
strictly LALR(1) but I think any- 
thing more precise would be 
obscure and would hinder people’s 
learning the language, or at least 
from understanding what was 
intended. If in fact you are doing a 
strict grammar you would have to 
handle things like the typedef 
names and dangling elses, both 
of which are important problems, 
but not really ones that need to be 
treated in an explicit fashion. 


CJ: Are you quite happy with 
the semantics and restraints being 
in English? 


Harbison: Semantics is 
another issue. I have always felt, 
and our opinion in the book was, 
that you can describe something 
precisely if you are careful and the 
problems I see in other C books, 
and in some cases our C book and 
in the Standard, are not cases in 
which the lack of a formal notation 
hurt. Rather, they are cases in 
which people simply didn’t think of 
all the situations that needed to be 
described. Formal notations have 
not really caught on. 


CJ: Prior to getting involved 
with C, what was your language 
background? 


Harbison: The algebraic 
languages mostly — FORTRAN, 
Pascal, Bliss, Ada. I had done some 
Lisp and SNOBOL work. 


CJ: So C really wasn’t a 
surprise in the sense of anything 
radical? 


Harbison: No. Guy and I both 
felt that although we did not spend 
all our waking hours programming 
in C, it was basically the same as 
Pascal, Bliss and the other algebraic 
languages that we already knew. 
We understood the underlying 
language concepts well and adapt- 
ing to C’s particular variations was 
not difficult. 


CJ: What about pointers? 


Harbison: The Standard is 
fixing a lot of the problems in the 
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area of data types especially by res- 
tricting the conversions between 
pointer and integer types. Experi- 
ence shows that there is no real 
need for the ability to go back and 
forth easily as long as you can con- 
vert from one to the other explicitly 
with a cast. A lot of this changing 
pointer types automatically is not 
necessary; it is a minor notational 
convenience that can lead to awk- 
ward portability problems. 


CJ: Things like (void *) 
just take it one step further to 
accommodate new architectures I 


guess. 


Harbison: Yes. But that was 
probably more of a theoretical than 
an actual problem. 


CJ: Does that mean that a 
pointer to void won’t mean a lot 
to most people? 


Harbison: I think it will. The 
uses for (void *) are common 
but people got away adequately 
with using (char *) for a long 
time and they probably still will. 


CJ: What class of problems is 
C best suited for? 


Harbison: Certainly C’s forte 
is systems work. I don’t know that 
C has particular features that give it 
such a distinct advantage. It has a 
lot of very nice features that make 
programming in C, especially for 
experienced programmers, rather 
good. However, it tends not to sup- 
port the kind of industrial strength 
programming where maintenance 
over a long period is a concern. It 
does not have good interface 
specifications; it allows too many 
things to be done behind your back 
and does not have function 


| think the [proposed 
ANSI] grammar is better 
than the C community 
has had. 


argument checking in pre-Standard 
versions. I think the pointer arith- 
metic is probably the most obvious 


feature that is not simply syntactic 
sugar. The ++ operator applied to 
an integer variable is really just 
Syntactic sugar; however, when 
applied to a pointer it is something 
significant as well as convenient. 


CJ: Let’s talk about code gen- 
eration and efficiency. 


Harbison: Pascal, Modula-2 or 
Ada compilers can generate object 
code that is just as efficient as any- 
thing you could do in C. I think for 
a long time programmers were not 
convinced of that and they needed 
the reassurance that here was C 
with a bunch of operators, like ++ 
that really did map directly to the 
VAX or PDP-11 instruction set. 
Hence, they had faith that you 
would get good code from it. 


Pascal, Modula-2 or Ada 
compilers can generate 
object code that is just 
as efficient as C. 


CJ: Are you saying that the 
compactness of code generation in 
C is not necessarily better but that 
it is in the implementer’s realm to 
do a good job with any of several » 
languages? 


Harbison: It is true that most 
run of the mill compilers will gen- 
erate better code for C than they 
will for Pascal or Ada but I think 
that is more of a reflection on com- 
piler implementation than anything 
to do with the nature of the 
language itself. 


CJ: When you write C code, 
how important is it for you to have 
an understanding of code genera- 
tion? 


Harbison: There are several 
ways to discuss that issue. On the 
one hand when you talk about pro- 
gramming large projects, things that 
are supposed to live for a long time, 
I certainly believe your primary 


concern ought to be maintainability 
and readability, not efficiency. 
Efficiency is very important when 
you choose your algorithms or your 
data structures but when you actu- 
ally get down to programming your 
implementations, in most cases it is 
wrong to write something that is 
more obscure in order to get some- 
thing that is more efficient. 


All the experiments show that 
most of your time will be spent in a 
very small part of the code and if 
you want to spend some time 
optimizing the 5-10%, or the one 
file where efficiency is_ really 
important, then you can make a 


case for that. But to run around 
replacing all your arrays by pointers 
and doing similar things that might 
make your code less readable is the 
wrong approach as far as I am con- 
cemed and C does encourage you 
to do that. It makes pointer arith- 
metic so good that a lot of pro- 
grammers will use that rather than 
the array notation which, for many 
applications, is more natural. 


CJ: Is there a_ significant 
penalty using arrays versus 
pointers? 


Harbison: If you are going to 
walk over an array of structures and 


you simply write the obvious loop 
using array indexing, then if you 
look at the code generated you will 
probably see a bunch of multiplica- 
tions and additions. That is, you 
will multiply the array index times 
the array element size in order to 
get the next pointer. That multipli- 
cation can be expensive in small 
loops executed many times. In C 
you will be tempted to rewrite that, 
stepping a pointer across the array 
thus eliminating the multiplication 
of the index and turning it into a 
simple addition. That is fine and 
will be more efficient. An optimiz- 
ing compiler on the other hand will 


Essential Communications Library $185 


e Comprehensive, reliable functions with source 

e Interrupt driven up to 9600 baud 

e XON/XOFF and XMODEM supported 

e Transfer files with one function call 

e Hayes compatible modem support 

e Thorough manual & asynch tutorial 

¢ Compatible with major C compilers, Pascal soon. 


BreakOut Asynch Debugger $125 


e Test protocols, monitor lines 

¢ Window interface, on-line help 

¢ Single key commands and macros 
e ASCII/Hex “Scratch pad” editor 

¢ Capture/send data in buffers/files 


¢ Detailed manual with sample screens 
e Requires PC/XT/AT or true compatible 


Essential Communications/BreakOut Combination Package $250 


ESSENTIAL SOFTWARE, INC. 
P.O. Box 1003 Maplewood, NJ 07040 914/762-6605 
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Essential Graphics $250 


Pascal e Fortran e C 
Fastest Library Available 
Powerful and Easy to Use 
Major Graphics Boards 


Filling, Get & Put 
Ten Character Fonts Inc. 


C Utility Library $185 


e New Release - Version 3.0 

e 400 C Functions, Source Included 

e Pop-up Windows and Menus 

e Fastest Screen Output Available 

e Strings, Files, Keyboard, Mice, DOS 
e Disable Ctrl-Break, Disk Drive Status 


ESSENTIAL SOFTWARE, INC. 
P.O. Box 1003 Maplewood, NJ07040 914/762-6605 


ar Circle 115 on Reader Service Card = 


A7 e THE C JOURNAL 


recognize the first loop and will 
eliminate the multiplication througn 
an optimization called strength 
reduction and will, in fact, generate 
object code that just increments a 
pointer into the array. So in the 
end, the two pieces of code from a 
good compiler would be about the 
same. 


CJ: Had you ever worked with 
a case sensitive language before? 


Harbison: C was the first one. 
At first, I thought it was a real pain. 
And so did most people I was 
working with. But after you have 
been using C for a while it certainly 
becomes much less_ bothersome. 
You do need to be consistent in the 
spelling of identifiers. Case sensi- 
tivity, I think can improve program 
readability and maintainability. On 
the other hand it does leave you 
open for some obscure program- 
ming. A program whose identifiers 
differ only in the case of letters can 
be very obscure but that is another 
case in which C gives the program- 
mer an opportunity to be obscure 
and to do bad things although it 
doesn’t force him to. 


CJ: Do you see C as being an 
‘‘expensive’’ language? 


Harbison: It is not clear to me. 
The choice of language might be 
viewed as choosing a language like 
C or one like Ada. The hypothesis 
is, without much data to support 
this besides my gut feeling, is that 
for very large projects C will be 
more expensive in the long run for 
maintainability reasons. It will be 
cheaper in the short run because it 
will probably be faster to bring up 
C programs that work. Whereas in 
Ada the compiler more or less 
enforces a better module structure 
upon you, in C it is always up to 
the programmer. And over a long 
period C programs will tend to be 
less well structured unless you put a 
lot of effort into it. 


CJ: Is portability of interest to 
your marketplace? 


Harbison: Yes, because we 
move code from machine to 
machine as we develop new code 
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generators or aS we rehost com- 
pilers on different machines. 


CJ: Do you think portability is 
overrated in C? 


Harbison: It is funny. The 
general feeling in the industry is 
that C programs tend to be portable 
even though you can point to any 
number of features in the language 
which would make it non-portable. 
My personal feeling is that the 
environmental and _ algorithmic 
issues that really do affect portabil- 
ity tend to be the same across all 
languages so that people just don’t 
think about them. 


What has really helped C is the 
fact that the majority of C imple- 
mentations came from a common 
root and consequently, there are 
very few language problems in 
going from one C implementation 
to another. Especially if they are 
both running the UNIX operating 
system. The library routines also 
tend to work OK for the normal 
cases, and so most people who are 
porting applications that are not 
stressing the boundaries of the 
library, are quite successful. 


CJ: Do you see any shortcom- 
ings in the proposed Standard? 


Harbison: I think almost all 
implementations are going to be 
forced to support the old-style C 
programming in some areas, partic- 
ularly the non-prototype function 
declarations. I think that when the 
Standard goes out for formal public 
review we will get a lot of disagree- 
ment with trade-offs that we made. 
Some people will wonder why we 
didn’t make the trade-off the other 
way. Hence the existence of the 
rationale document. This is a very 
important part of the Standard. 
Time will tell whether or not there 
are any Serious omissions, and this 
will come about after more people 
implement the language. 


CJ: How long will it take for 
the Standard to permeate the real 
world? 


Harbison: I think we will 
learn a lot when people try to write 


programs or try to modify their pro- 


grams so that they will operate 
under both Standard C and the 
older version. The thing that makes 
me think that the ANSI C may take 
off faster than other Standards is 
the unusually high participation of 
the implementers in the committee. 
Implementers from almost all the 
major manufacturers who have C 
compilers are participating, and in 
some cases are already moving to 
implement the new ANSI language. 
How fast it takes over I am not 
sure. There may be a strong user 
desire to retain the old compilers 
and there may be a push to have a 
compiler that can operate in both 
modes although that would be 
difficult. What happens in UNIX 
environments will set the tone for 
other implementations. 


CJ: Let’s take the case where 
the Standard has been out for a 
year. If I, as a user, have an invest- 
ment in hundreds of thousands of 
lines of source code are you sug- 
gesting that I should probably hang 
on to my pre-Standard compiler and 
use that for maintenance because a 
newer, perhaps conforming com- 
piler may break existing code? 


Harbison: No. I think what 
you will see is people doing a lot of 
conditional compilation, having 
both prototype and non-prototype 
function declarations living in the 
same source simultaneously for 
some time. 


CJ: But people with a large 
investment in existing code might 
not be in a hurry to go forward and 
use a conforming compiler. 


Harbison: I certainly don’t 
think that they will rush ahead to 
change until the Standard is first of 
all official and then is clearly being 
implemented by a large number of 
vendors. 


CJ: By change, do you mean 
wholesale conversion? 


Harbison: I think you can 
make incremental changes. It will 
require some conditional compila- 
tion based on whether you are using 
a Standard-conforming compiler or 


not. The introduction of prototypes 
is probably one of the first things 
you will want to do, but I think an 
implementer in a commercial 
environment would probably want 
to make those changes to help his 
maintenance problems, but would 
probably make them conditional so 
that he can still compile his pro- 
grams under an older compiler if he 
needs to. 


CJ: Thank you. 
Ada is a registered trademark of the 


United States Government — Ada 
Joint Program Office. 


coo 


Scott Harbison 


/ 


missing... 


Interactive-C™ 


Revolutionary New Programming 
Development System 


At last, a full-function, professional- 
quality C development system to optimize 
your creative abilities. Stop waiting for 
editors, compilers, and linkers that waste 
your valuable time. Stop debugging in 
hex at the machine level. Easily DOUBLE 
or TRIPLE your productivity with this 
totally-integrated, fully-interactive pro- 
gramming environment: 


e Complete K & R interpreter 

e Full-screen program editor 

e Source-level symbolic debugger 
e Command processor shell 

e Execution profiler 


Interactive-C requires an IBM PC or 
100% compatible, MS-DOS 2.0 or later, 
and 256K RAM. Interactive-C is available 
for only $249 and comes with a risk-free 
30 day money back guarantee. 


Enjoy the combination of power, flex- 
ibility, and ease of use that will make 
Interactive-C the most valuable product- 
ivity tool you own. Order Today. 


What you’ve been 


e Single or dual CRT configuration 

e Multi-window user interface 

e 40x25 and fultscreen graphics support 
e Detailed syntax & rur-time diagnostics 
¢ Precise cursor error positioning 

e Trace, breakpoints & data watchvalues 
e Several varieties of STEP 

e Full-screen traceback 

e Command-level “immediate” mode 
e Multiple source files 

e Compiled module interface 

e Much, Much, Morel!! 


For more information or to place an 
order contact: 


=o» IMPACC Associates, Inc. 
P.O. Box 93 
Gwynedd Valley, PA 19437 
215-699-7235 


Trademarks: IBM - International Business Machines; MS-DOS - Microsoft Corp.; Interactive-C - IMPACC Associates 
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Floppy Disk Cat Demonstrates Sequential Logic 


Users’ 
Group 


Over 90 volumes of public 
domain ‘‘C’’ software including: 


compilers 
editors 
text formatters 
communications 
packages 
e many UNIX-like tools 


Write or call for more details 


The C Users’ Group 
Post Office Box 97 
McPherson, KS 67460 
(316) 241-1065 
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Video Training 


A Programmer’s 
Introduction to C 


Reviewed by Rex Jaeschke 


by Ray Swartz 

Berkely Decision/Systems 
150 Belvedere Terrace 
Santa Cruz, CA 95062 
(408) 458-0500 

$400, VHS/Beta 


The training material consists of 
two tapes, one of 2 hours and the 
other of 1'/ hours. They are 
recorded at high speed for better 
quality. The 110 page workbook is 
printed single-sided, making plenty 
of room for student notes. 


The material is broken into the 
following sections: Introduction; 
Fundamentals of the C language; 
Data types, Operators, Expressions; 
The C Language in Action; Read- 
ing input and creating functions; 
Arrays; and Pointers. The last four 
chapters contain almost all of the 
material and each also contains a 
reasonable set of problems. The 
worked solutions to these are listed 
in an appendix. 


The workbook is in note form 
and reflects the content of the 
videotapes. It does not contain 
much other narrative or background 
material so the student needs at 
least one other introductory text. 
Since the course provides an over- 
view of the C language, the brevity 
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& Things 


of the notes is not a shortcoming. 
However, it does provide a solid 
basis on which to begin program- 
ming in C in eamest. 


The graphics used are simple 
yet adequate and the class leader 
varies the pace and his mannerisms 
and speech enough to keep you 
from losing concentration. Many 
examples presented are changed 
and/or executed on a terminal dur- 
ing the sessions, providing a more 
realistic environment. Introducing 
pointers can be quite difficult yet 
Swartz does an admirable job 
without leaving the user more con- 
fused than when they started. 


All round, the tapes are reason- 
able well produced and scripted and 
the tape set is recommended for 
anyone who needs to get up and 
running quickly and can’t afford the 
time to attend public classes, which 
incidentally, are quite a lot more 
expensive. 


Books 


Reliable Data Structures 
inc 


Reviewed by Rex Jaeschke 


by Thomas Plum 
Plum Hall, Inc. 

1985 250 pages 
ISBN 0-911537-04-X 


‘‘This book is meant to follow 
an introductory book on C. It 


assumes that you have successfully 
written some programs in C and 
that you are familiar with the basics 
of variables, operators, functions, 
pointers, and structures. It does not 
assume that you know the more 
advanced features such as pointers 
to functions, pointers to structures, 
dynamic allocation, enumerations, 
typedef, bit-fields, unions, 
FILE I/O, or dynamic data struc- 
tures; these will be covered herein. 
Also covered are rules for reliable 
programming, programming with 
no surprises.”’ 


The chapters cover the follow- 
ing topics: Preprocessing, Scalars, 
Arrays, Pointers, Standard File and 
Terminal I/O, Structures, Dynamic 
Data Structures, and Files. The lone 
appendix contains a summary of all 
of the reliability rules introduced in 
each of the chapters. There are 
approximately 50 rules identified 
and examples of theme are: Use a 
consistent set of project-wide 
defined types; Test errno before 
using results from the math func- 
tions; If a variable has an initializa- 
tion, its declaration should have a 
source line by itself; and Names 
with leading underscores should 
only appear in code that is privy to 
the internal details of the associated 
data structure, not in ‘‘user-level’’ 
portable code. The second part of 
the appendix contains useful infor- 
mation about the proposed ANSI C 
Standard and other programming 
tips. 


WI1ZARO C 


The new Wizard C version 3.0 sets new records for all out speed! 
It leaves other C compilers in the dust! When your project de- 
pends on that last ounce of speed, choose Wizard. 


{/ 


The following SIEVE benchmark was run without register vari- 


able declarations on an IBM/PC with 640K memory and an 8087. 
Code Size EXE Size 


Exec [ime 


Wizard C 3.0 : 6.8 130 7,766 
Microsoft Sf i335 186 7,018 
Lattice ot at 164 20,068 


Fast executable code, with multiple levels of optimization. 


Six memory Models, supporting up to | megabytve of code and data, 
plus mixed model programming. 

Effective error diagnosis, including multiple source file cross-checking 
of function calls. 


A comprehensive runtime library, including fully portable C functions, 
MSDOS and 8086 functions. 


8086, 8087, 80186 and 80286 hardware support. 
Full Library Source Code included with package. 


ROM based application support, including a ROM development 
package available to create Intel Hex files. 


Fully ANSI compatible language features. 
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“Wizard's is the best compiler 
today. What it does have is library 
source for a very large library, 
Rood documentation, excellent 
support, and lint. 

“Our choice if we could make our 
own? We would take Wizard...” 


Dr. Dobb's Journal 
August 1986 


‘,The compiler’s performance 


makes it very useful in serious 
software development.’ 


PC Tech Journal 
January, 1986 


‘\wwritten by someone who has 
been in the business a while. This 
especially shows in_ the 
documentation. 


Computer Language 
February, 1985 


For debugging, the compiler 
emits full Intel debugging in- 
formation including local sym- 
bol and type information. 


For stand-alone applications, 
we supply a ROM develop- 
ment package that carries 
your program all the way to 
Intel Hex files ready for a 
PROM burner. 


Wizard C $450.00 

ROM Development Package $350.00 

Combined $750.00 

Automatic Upgrade Program 
(annual fee) 


Make 
Math 87 Library 


WizksRo 


SYSTEMS SOFTWARE, INC. 


11 Willow Court, Arlington, MA 02174 


(617) 641-2379 


Since Plum is Vice-Chair of the 
“ANSI C Standard Committee, he is 
understandable knowledgeable on 
the topic and references to that 
Standard, and its implications, are 
many and relevant. All source code 
examples are available on PC-DOS 
diskette(s), for a nominal charge, 
from C Users’ Group, PO Box 97, 
McPherson, Kansas, 67460, USA. 
Telephone (316) 241-1065. 


This book is of the same, good 
technical quality as Plum’s earlier 
efforts, and along with Efficient C, 
a joint venture with Jim Brodie, 
qualifies as one of the five or six C 
books that I regularly recommend 
that serious C project managers 
buy. 


Green Hills Software offers a 
family of highly optimized C com- 
pilers for the Intel 80386 (with 
fpp), 680x0, the Fairchild Clipper, 
NS32000, Ridge RISC workstation, 
and the Weitek ACCEL chip fam- 
ily. These compilers are plug- 
compatible with UNIX cc. 


Green Hills Software, Inc. 
425 East Colorado St, 
Suite 710 

Glendale, CA 91205 
(818) 246-5555 
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Zeta-C is now available for the 
Texas Instruments Explorer Lisp 
Machine. This is the same compiler 
they provide on the Symbolics 3600 
Lisp machine. The compiler is com- 


patible with UNIX System V and 


BSD 4.2. compilers and includes 
extensions defined in the proposed 
ANSI Standard. Cost is $5,800 for 
the first CPU. 
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New Arrivals 


e Complete C Language Pro- 
gramming for the IBM PC, by 
Douglas A. Troy. Little, Brown 
and Company, Boston MA, 
1986, 500 pages, ISBN 0-316- 
85311-9, $16.95. Plenty of 
code examples although source 
is printed in dot matrix format. 
Provides good coverage of C, 
the PC architecture, and soft- 
ware engineering. 


e C for Programmers by Leen- 
dert Ammeraal. John Wiley and 
Sons, 1986, 110 pages, ISBN 
0-471-91128-3, $19.95. ‘‘A 
Concise Guide for The Experi- 
enced Programmer’’. It seems 
to have the goods if you don’t 
mind all your examples printed 
in italics. 


ZETA-SOFT, Ltd. 

94 Sciarappa 

Suite 2 

P.O. Box 139 
Cambridge, MA 02141 
(617) 868-4634 
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Need an expert system develop- 
ment environment for C? Then 
CxPERT may be for you. It 
operates on DOS-based systems 
using the Lattice compiler and 
translates knowledge base modules 
into C source. Requires DOS V2.x 
and 128KB memory. A free demo 
diskette is available. 


Software Plus 

1652 Albermarle Drive 
Crofton, MD 21114 
(301) 261-0264 
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e C Primer Plus by Waite, Prata 
and Martin. Howard W. Sams 
& Co., 1984, 530 pages, ISBN 
0-672-22090-3, $22.95. ‘‘User 
Friendly Guide to the C Pro- 
gramming Language.’’ UNIX 
and 8088-specifics with plenty 
of examples and problems. Well 
laid out and comprehensive; 
includes a tear-out reference 
card. 


e Advanced C Primer++_ by 
Stephen Prata. Howard W. 
Sams & Co., 1986, 500 pages, 
ISBN 0-672-22486-0, $23.95. 
Definite 8088 flavor along with 
assembler examples. Thorough 
coverage. Note that this book 
has nothing to do with the C++ 
language. 


oo 


Products and Services 


Phoenix has announced 
PSource, a source code control sys- 
tem for DOS-based systems. It is 
modelled after UNIX’ SCCS. It 
requires 512 KB and is priced at 
$495. 


Phoenix Technologies Ltd. 
Norwood, MA 
(617) 769-7020 
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C86PLUS is the latest release of 
Computer Innovations’ DOS C 
compiler. They claim that it can 
beat the Microsoft V4 compiler in 
speed, with which it maintains 
Close compatibility. This new pro- 
duct is about 70% faster than their 
previous compiler, Optimizing C86 
V2.3. C86PLUS. contains many of 
the extensions contained in the pro- 
posed ANSI Standard including 
function prototypes, const and 
volatile type modifiers and the 
new long double type. 
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special Book Offers for C Journal Subscribers 


UNIX System Administration_ 
by David Fiedler and Bruce Hunter 


Written by two noted authorities in the UNIX" field, this book enables you to administer a UNIX system on any size 
computer and installation. Informative, step-by-step guidelines tell you how to bring up the system, use fsck, run back- 
ups, set up and use cu and uucp, get printers, terminals and modems hooked up and running, and keep your system 
secure. Appendices include detailed information on RS-232 connections and uucp connections. For people with a work- 
ing knowledge of UNIX who have the task of running the system. Paperback, 320 pp. 


O Yes, please send me ____ copies of UNIX System Administration at $24.95 each. Add $2.00 p/h for first book, $1.00 
each additional book. CA residents add 6% sales tax. 


™ 
Nutshell Handbooks 
‘‘The Nutshell series is precisely what is needed for our users and programmers alike. They are thorough treatments of very specific 


areas of UNIX, rather than introductory texts trying to cover everything. They also complement the UNIX manuals quite nicely, 
because of their readability. I highly recommend them.’’ 


— Brian Yost, Director of Software 
Micro Business Associates / RDDR Inc., Netcong, NJ 


The Nutshell Handbooks are produced for InfoPro Systems by O’Reilly and Associates. They are concise, easy-to-follow 


references for mastering difficult subjects and offer examples, as well as sample code where appropriate. Book lengths 
vary by title from 72 to over 100 pages. 


Quantity Title Quantity Title 
anne Reading and Writing Termcap Entries peu Programming with Curses 
aaeat Managing UUCP and USENET oie Using UUCP and USENET 
ay Managing Projects with make Se Learning the vi editor 
ears Learming the UNIX operating system 


1 Nutshell book costs $8.00 (plus $1.50 p/h) Total: $9.50 » Any 2 books are $15.00 (plus $2.00 p/h) Total: $17.00. 
=> SPECIAL OFFER! Pick any 3 for just $22 including postage and handling! <— 


O Save even more! Send me the whole set (all 7 books) for only $50 including shipping/handling (add $3.00 tax on CA 
orders). For larger quantities please call us at 916-677-5870. 


InfoPro Systems, PO Box 220, Rescue, CA 95672 


_ UMy check or money order is enclosed, payable to InfoPro Systems 
O Company purchase order number 


Please charge my: MasterCard O VISA Card # Exp. Date 
Signature 


Name 
Company 
Address 

City State Zip 
Telephone 


Our Money-Back Guarantee on all products — if you are not satisfied with any book, return it for a full refund. Please note that all books will be 
shipped out at 4th class book rate, so allow 3 to 5 weeks for delivery (although it normally takes less time). If you need them in a hurry, call us 


directly at (916) 677-5870 for special arrangements. This offer good only in the U.S.A. and Canada. For overseas orders, please contact us by mail 
or Telex 151296369 INFOPRO. : 


The C Journal is a trademark of InfoPro Systems. : | 53 res 
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Puzzle Corner 


[Ed — Due to space limitations, the Puzzle Corner was 
omitted from the previous issue. Thanks for all your 
mail and solutions. ] 


The New Puzzle 


I came across this ‘‘program’’ while scanning one 
of the networks recently. It was submitted by Ed Lyck- 
lama. If you have some patience, perhaps you can let 
me know what it does. While most of my compilers 
produce the same (correct) result, others die hopelessly. 


There is an old saying that I really use a lot. Noth- 
ing is a complete waste — it can always serve as a bad 
example. And it’s probably applicable here. The choice 
of identifier names leaves something to be desired to 
say the least. 


SOCTING «52-70 -Wrice 
#define ooo (unsigned) 
#define. oo 1 

*detine  o. char 
#define oo goto 
#define oo read 
#define o o for 
#define o_ 
FOSTING C5 LE 
#define oo 0 
PACT ING Ul 6 ye 
RVOLGE oe On re POOR ey) 
edet ing. 3s ae 
((0_0 <<(0 0 <<o o ))\ 
+107 0 <6 0.) 1) j +o Gc. \ 
<<(0_ 0 <<(0 0 <<o © ))) 


ogi Sr See. SOG yo Fee ae 
mee USE ee OL ei Aes ears ye eakep ; 
Se ee ee iat Lage ® ae Ser 
Spe Sa ae tek O40 20 7p ay 
Soo G0 0. ee EO Oe: 

se FEO; FH O(O 0.7 
MN PROC) 5c ee 

SLO 20S Wy O Oe) 
De see Se aOR & See ae ae ; 
OA EG, “NTS, O03) 3 
OF aay a ceo eee 0,454: 20074 
DO ps pe ORD 

OO g: 


/* [it looks like tty noise] */ 
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The Previous Puzzle 


static struct: sf 


Struct. s:-sz; 


While sl has class static, s2 has class 
auto. In fact, if you omit s1 from the first declara- 
tion, the keyword static has no meaning and is 
ignored. This would then be a classical case of ‘‘a 
correct but useless declaration.”’ 


Regarding the proof, static variables, and the 
members of static aggregates, are initialized to the 
value zero cast to their type, by default. However, sim- 
ply displaying the contents of s2’s members may still 
print zero values. By calling a function, or otherwise 
causing the stack to have some non-zero residue on its 
unused portion, before calling function f, should result 
in some ‘‘garbage’’ values being displayed. 


Craig Banning thought he could prove this by 
attempting to use an initializer list with s2 and hope- 
fully getting something like ‘‘auto aggregate may not be 
initialized.’’ To his surprise, his compiler accepted it. 
While this is not strictly K&R behavior, it is accepted 
by many compilers (and the ANSI Standard). 


Other good discussions were received from Leon 
Cejas and Greg Comeau. 


Please submit puzzles and solutions to the Editorial 
address: The C Journal Puzzle Corner, 1810 Michael 
Faraday Drive, Suite 101, Reston, VA 22090. 


co 
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Computer Innovations, Inc. 
980 Shrewsbury Ave. 
Tinton Falls, NJ 07724 
(201) 542-5920 
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Need a Pascal-to-C converter? 
Maritime have Converter II. It con- 
verts the following Pascal dialects: 
Turbo, Apple Lisa, UCSD p- 
system, MT+, MS-Pascal, IBM- 
Pascal and Apollo DOMAIN. All 
source code is included in the price 
which varies from $5,000 to 
$10,000 depending on target. Site 
licensing is available. Conversion 
assistance and samples are avail- 
able. 


Maritime Infosystems Ltd. 
6660 Reservoir Road 
Corvallis, OR 97333 
(503) 929-2552 
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A new graphics library is avail- 
able from The Librarian, Inc. It is 
callable from CI-C86, MWC86, 
Lattice C and Microsoft C; also 
‘from various FORTRAN compilers 
on DOS. Source code is included. 
The PLOTHI library supports the 
Houston Instrument and DM/PL 
plotters and costs $175. PLOTHP 
supports HP and HPGL compatible 
plotters and also costs $175. 
GRAFLIB_ supports DOS _ video 
screens: $175. 


The LIBRARIAN, Inc. 
10506 Permian Drive, 

P.O. Box 1733 

Sugar Land, TX 77487-1733 
(713) 491-2088 
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A family of 680x0-based C 
compilers is available for DOS, 
Xenix and UNIX. Source code is 
provided for the library. 


Software Development Systems, Inc. 


3110 Woodcreek Dr. 
Downers Grove, IL 60515 
(312) 971-8170 
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BARTENDER is a set of bar 
code algorithms that enable more 
than 21 bar code standards to be 
read. Source code is included and 
can easily be ported. Cost is $295 
for each bar code required. 


RFW Research 
2919 Priscilla Ave. 
Parma, OH 44134 
(216) 884-9927 
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Alcyon has a family of 680x0 
optimizing C compilers. Also real- 
time UNIX software for the 
VMEbus. 


Alcyon Corporation 

5010 Shoreham Place 

San Diego, CA 92122-3954 
(619) 587-1155 


«ry Circle Reader Service #179 = 


JMI has released a new version 
of BASTOC, a BASIC-to-C transla- 
tor. The new version supports 
Microsoft’s V4 compiler. BASTOC 
is available for DOS, UNIX and 
Xenix. 


JMI Software Consultants, Inc. 
904 Sheble Lane 

P.O. Box 481 

Spring House, PA 19477 

(215) 628-0846 
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(Unsigned continued from p. 64) 


Feuer’s C Trainer, an interactive 
instructional package for teaching 
C. This package includes an inter- 
preter and text book from 
Prentice-Hall. Alan is the author 
of the very popular C Puzzle Book, 
a must in every C shop’s library. 
Prices on the new Cromemco ver- 
sions are $2,000 for the interpreter, 
$1,200 for the run-time analyzer, 
and $220 for the training package. 
Also enquire about their C-to- 
English and English-to-C utilities. 
These take a C declaration and 
explain it in English, or take an 
English description of the declara- 
tion you want and produce it. It 
certainly saves some _head- 
scratching when your neéd to read 
or write a declaration for those 
pesky pointers to pointers to func- 
tions that return a pointer to a 
pointer to an array of structures. 
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Use the postpaid Reader Ser- 
vice Card bound into this 
issue to request free informa- 
tion from our advertisers. 
Just circle the appropriate 


numbers and drop it in the 
mail. 
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The Derived Type size t 


John M. Hausman 
Tandem Computers 
Cupertino, CA 


Introduction 


The ANSI X3J11 committee recently submitted the draft proposed C Standard for public review. The Standard 
will provide a path for various dialects of C to converge to one common, portable language. As more and more 
compilers adopt the principles spelled out in the Standard, it will be easier for you to write code which can easily be 
ported from one computer to another. 


In order to allow operations to be more portably defined, several ‘‘pre-defined’’ types have been added to tradi- 
tional C by the C Standard committee. One of those types is size t. 


The type size t is defined by the draft Standard to be “‘the unsigned integral type of the result of the 
sizeof operator’. Whereas the sizeof operator traditionally returned an int, it now retums an unsigned 
value whose size is defined by the compiler writer. A few questions come to mind. Why change the type returned 
by sizeof? How does this affect your code? How can you write new code which uses size _ t to be as portable 
as possible? 


First, why invent size t in the first place? On modern hardware, an int (often, 16-bits) is not always big 
enough to hold the size of an object. C needed a type which could, for any given computer, be guaranteed to be big 
enough to hold the size of any object and yet not be too large (and thus wasteful). size t is that type. It will 
make it easier for you to move code from one computer to another, or from one memory model to another on the 
same machine. The IBM-PC, for example, has 16-bit and 32-bit addressing modes. If you are using a mode of the 
compiler which always generates 16-bit addresses, size t could be an unsigned short. If you switched to 
a mode where addresses were 32-bits, size t will be defined to be a unsigned long. If you have written 
your code with this move in mind, the conversion should take little or no effort. 


How does size _ t affect your existing code? If your program runs on a machine where the size of the largest 
object can be represented by an int and you are are not interested in having portable code, you probably don’t 
have to do anything when your compiler starts supporting size t. If, on the other hand, you want to take advan- 
tage of this new feature for maximum portability, there are some changes you will have to make. 


THE C youRNAL « 56 


AORTIC 


Sa a ae ea 


ink about it, a full year of useful articles and infor- 

mation all about the C language. ~The C Journal 
gives you all you need to work with C on any 
machine: IBM PC, UNIX-based, Macintosh, or CP/M 
— micro, mini, or mainframe. Look forward to each 
big quarterly issue for: 
« in-depth reviews and feature articles C 
compilers, interpreters, function libraries, and books. 
<r hints and tips — help you work better and faster. 
ar interviews — with C entrepreneurs and experts. 
« News and rumors from the rest of the industry. 


ubscribe today to the only magazine that is dedica- 
ted specifically to C — The C Journal. Just send 
a check for $18 (save 35% off the newsstand price! 


to: 
===InfoPro Systems’ 


PO Box 220, Rescue, CA 95672 


Or call toll free 1-800-628-2828 ext. 849 for charge 
Card orders. 


LALO TE RT TT TTT TET TEE 


Se ee 


Price $6.95 


THe G JOURNAL” 


Sources and Resources for All C Programmers Fall 1985 


as 


Small C: Interview with Ron Cain 

A Tale of Three EMACS 

Catching Common C Bugs 

Bruce Hunter: The UNIX Environment 
More MS-DOS Library Reviews 

Tom Plum: ANSI C Report 


MasterCard 


ERROR RRS 


THE G JOURNAL’ 


Trademarks — IBM PC: IBM Corp.; UNIX: AT&T Bell Labs; Macintosh: Apple Computer Corp.; CP/M: Digital Research Inc.; The € Journal: InfoPro Systems. 


ar Circle 128 on Reader Service Card = 57 e THE C JOURNAL 


size_t asa Function Return Value 


The draft proposed Standard defines the following functions which return values of type size t: fread, 
fwrite,.strcoll, strespn, .strspn,. strlen. 


The sizeof operator, while not strictly a function, can be put into this category also. If your code calls one of 
these functions, you need to examine the code and change it if necessary. If you can be sure that the return value 
from the function will always fit into the variable defined for it, all you will have to do is cast the return value of 
the function. However, if the return value might not fit into the variable which it is assigned to, you will have to 


change the type of that variable. Be aware that that change might have effects on other expressions which use the 
variable. Consider the example: 


int len; 
len = strlen(name) ; 


Technically, len should be declared to be of type size_t. Such a use would look like this: 


Size. t ién; 
len = strlen(name) ; 


This change, however, might have other hidden effects on the code. Consider, for example, what will happen if 
size t is a different size that int and len is passed to a function which expects an int. On many systems, 
the error will not be detected and the parameter stack of that function will be trashed. 


A simpler change would be to cast the return value of strlen to int and do the assignment. This will only 
work if you can be sure that the value will fit into an int. Often, that assumption can safely be made. If name 


holds a person’s name, for example, you can be sure that it will not be longer than 32767! An example of such a 
use is: 


int len; 
len = (int) strlen(name) ; 


Of course, the best way to use this feature to write portable code is to write the code using size_t to declare 
any item which holds the size of an object. Here, however, we are concerned with porting existing code. 


size t asa Function Parameter 


The draft proposed Standard defines the following functions which take a parameter of type size t: 


bsearch calloc 

fread fwrite 

malloc memchr 

memcmp memcpy 

memmove memset 

qsort realloc 
setvbuf strcoll 
strncat strncmp 
strncpy 


As mentioned above, size_t can cause problems as a function parameter also. For example, consider the fol- 
lowing example which passes the result of sizeof to a function: 
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void func(i) 

arnt ay 

{ 

/* some code here */ 


} 


main () 
{ 
func(sizeof (big struct)); 


} 


If size_t is a different size than int, this function will not behave as expected on systems where sizeof 
returns size t. There are a number of ways to catch this. The best is to use function prototypes (also defined in 
the draft proposed Standard) to help you catch mismatches between a function’s formal parameters and its actual 
parameters. The compiler would detect the mismatch if the above example was written this way: 


void func(int i) 
{ 
/* some code here */ 


} 


main () 
{ 
func (sizeof (big struct) ); 


} 


To fix the problem, the actual and formal parameters must match. Again, if you can be sure that the actual 
parameter will fit into the type used for the formal, it is easiest to cast the actual parameter. If, however, the actual 
parameter might overflow the present formal, then the type of the formal must be changed to size t. As above, 


if you change the type of a variable (in this case, the formal), you must be careful to consider how that change will 
affect uses of the variable. 


size t in Macros 


When moving to a compiler which supports size t, you must be aware of macros which now 
evaluate to an object of type size t. For example, in the following fragment of code, the type of ARRAY SIZE 
might change when moving from one memory model to another. 


#define ARRAY SIZE MAX ARRAY * sizeof (element) 


void *alloc mem(size) 
int size; 
{ 

/* some code here */ 


} 


main () 

{ 

char *p; 

p = alloc mem(ARRAY SIZE); 
} 


As with the previous example of passing a size t object to a function expecting an int, if the size of 
size t is different from the size of an int, this code will not work. The solution, of course, is the same. How- 


ever, you must be especially careful of uses of the size_t type inside macros because they can be much harder to 
find. 
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Conclusion 


We have examined two categories of code where the use of size_t might require changes in your code. They 
are size t as a function parameter and as a function return value. Lastly, be sure to check macros to be sure 
there are no hidden dependencies on size_t. Adapting code to a compiler which supports size t might 
require changes to code which already works perfectly on your current system. The result, however, will be a pro- 


gram which can much more easily be ported to other systems or to other memory models on your current system as 
your needs grow. 


[John Hausman is Tandem’ s representative on the X3J11 Standards Committee.] 
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Are You Missing Back Issues? 


The first two issues of The C Journal are sold out! You can still purchase individual copies of Volume 1 
(Numbers 3 and 4) and Volume 2 (Numbers 1, 2 and 3) at $6.95 plus 1.50 postage and handling ($8.45 
total for U.S. and Canada only) each. Outside the U.S., payment must be in U.S. dollars drawn on a U.S. 
bank. Airmail shipping/handling costs are $3.00 to Europe and $4.00 to Asia. Sorry, we cannot bill you 
for back issues. Please send a check, money order, or MasterCard/VISA information (card number and 
expiration date) to Back Issues, The C Journal, PO Box 220, Rescue, CA 95672. 


Volume 1 Number 3 contained reviews of two competing EMACS editors, several IBM PC function 

libraries, and development packages. As part of our regular features we had an interview with Ron Cain 
(the developer of Small-C), an article on UNIX environment variables, a feature on the C pre-processor, 
and a look at some common programming errors. 


Volume 1 Number 4 focused on several aspects of portability problems. Articles covered efficiency, 

economics, and I/O considerations, the goals of the ANSI X3J11 committee, and an interview with Jim 
Brodie of Motorola, the founder of X3J11. Case studies included porting compilers from the VAX to 
68000, and from the IBM PC to the IBM 370. 


Volume 2 Number 1 covered efficiency, Data Hiding in C++, VAX VMS I/O implementation, side effects of 
expression evaluation, C compilers for mainframes, and the importance of scope to C programmers. The 
interview was with Tom Plum of Plum-Hall. 


Volume 2 Number 2 covered debugging with the use of static analysis tools and a case study of debug- 
ging large programming projects. Other articles covered object-oriented programming in C++, syntax- 
directed editors, C and RISC architectures, and a comparison of C and Pascal. The SPOT LIGHT inter- 
view was with Tom Pennello and Frank DeRemer of Metaware. 


Volume 2 Number 3 was our special ANSI C issue. Articles included a list of ANSI reserved words and 

identifiers, a description of the ANSI certification procedure, function prototypes, hosted program startup 
and termination, the ANSI preprocessor, pointers, floating-point arithmetic, trigraphs, and discussions of 
tie meaning of ANSI to optimizers and UNIX users. SPOT_LIGHT was on Larry Rosler of AT&T. If you 
plan to write ANSI-conforming C programs (or any C programs in the next five years) we highly recom- 
mend you hold onto this issue! 


If you're really desperate for an article from our first two issues we can provide you with a photocopy of 
that article. The cost is $2.50 an article (includes postage and handling). If you are interested, send us a 
note to the above address and we will send you a photocopy of the Table of Contents of the first two 
issues. Sorry, but we cannot photocopy an entire issue! 
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you who answered the question- 
naire, and to let you know that your 
remarks have all been noted (even 
the silly ones) and forwarded to 
Rex for consideration. 


While we weren’t surprised to 
find that many of you use C both at 
home and at work, it was interest- 
ing to see the wide range of 
responses to some of the questions. 
Here, in abbreviated form, are some 
of the statistics: 


¢ More than 75% of you are pro- 
fessional C programmers, and 


nearly 30% are programming 
managers. 


¢ One out of 6 C Journal readers 
have less than one year’s 
experience with the language, 
while 1 out of 8 have been at it 
more than five years. 


Publisher’s Platform 


‘57% use some variant of UNIX 


or XENIX, 79% use MS-DOS, 
and about 18% still do it with 
CP/M. 


The expected huge (75%) 
number of you use IBM PCs or 
the equivalent, followed by 28% 
using 68000-based variants, and 
25% with some sort of DEC 
equipment. A surprising 12% 
of you use mainframes or super- 
computers. 


We’re happy to report that 92% 
of you are regular subscribers to 
The C Journal and keep your 
copies for future reference. 


Your uses for C are many and 
varied. 45% of you do business 
programming, 42% write opera- 
ting systems and system pro- 
grams, 38% deal with DBMS 


and file access methods, 36% 
work in communications and 
graphics, 27% in real time or 
engineering work. 


As far as articles go, some 
preferences were related quite 
strongly. Advanced C articles are 
in great demand, along with product 
reviews, C on specific operating 
systems, ANSI topics, C on UNIX, 
new product announcements, and 
Doctor C’s column. On the other 
hand, few of you want to hear 
much more about ‘‘international’’ 
C! We have taken your interests 
into account when planning future 
issues — like the upcoming issues 
on Communications, Access Meth- 
ods, and Graphics — and hope you 
will continue to enjoy The C Jour- 
nal. 

— D. Fiedler 
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Mtention AUtAOrs 


We are looking for a few good authors. If you have been working on an interesting C-related project, 


we would like to hear from you with respect to writing a case study. Specific products can be mentioned 
provided the presentation is constructively critical and not marketing oriented. 


Other topics of interest to us are the use of C in such diverse areas as communications, data base and 
access methods, graphics, scientific and engineering applications, and commercial systems. We are also 
interested in receiving programming tips that include interesting and useful functions in source form. Code 
examples up to 100 lines or so will be considered for publication. Make sure your code is edited to fit 
either a '/s, 1/2 or full page column. 


We are thinking of starting a regular “Portability” column so if you have a reasonably good working 
knowledge of one or more target C environments and would like to get involved, let us know. Also, we 
have plans to reactivate the UNIX-C column as well as product reviews, so we are interested in “guest 
writers” for these projects. 


The prerequisites for writing for The C Journal are that you have something useful to say and that you 
can say it in reasonably conversational English. You need not have had anything published before — nei- 
ther have most of our previous authors — and no matter what your technical level, there are bound to be 
readers at the same level. So don’t under-rate yourself. 


lf you have an idea for an article on any of the above (or other) topics, contact Rex Jaeschke at the 
editorial office: The C Journal, Suite 101, 1810 Michael Faraday Drive, Reston VA 22090. The best 
approach is to mail in a brief abstract, three or four paragraphs should suffice, and include a home and/or 
business telephone number. 
Why not begin your writing career with The C Journal? 
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4. Do you recommend/purchase C develop- 
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MetaWare has released a ver- 
sion of their High C DOS-based 
compiler for the Intel 80386 run- 
ning in protected mode. Call them 
on (408) 429-6382 for details. Price 
is $895. Their compiler was used 
by IBM to port UNIX BSD to the 
RT/PC. In order to link C for the 
306, and °- ron. ..at,- you: < need 
386|ASM/LINK and 386|DOS- 
EXTENDER from Phar Lap, 
which cost $495 packaged with a 
debugger. The compiler and linker 
can be hosted on any DOS 
machine, not just a 386. Phar Lap 
are at (617) 661-1510. 


Gimpel Software has 
announced version 2.3 of their slick 
interpreter C-terp. It is compatible 
with both Microsoft V4 and Lattice 
V3. It contains a new virtual 
memory management scheme to 
allow very large programs. Also 
supports Xenix. (215) 584- 
4261...Gimpel’s main rival, 
Rational Systems has also released 
V2 of its popular interpreter, 
Instant-C. It compiles directly to 
machine code and can call (or be 
called by) Microsoft and Lattice 
object code. Supports hardware 
interrupt processing. (617) 653- 
6194. They have also announced 
Support for CSharp, a DOS-based 
real-time programming tool from 
Systems Guild, Inc. This enables 
interrupt service routines and device 
drivers to be developed and tested 
interactively. Csharp for Instant-C 
sells for $895. Current users of 
either product can get an upgrade 
for $495. A separate drivers pack- 
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by Rex Jaeschke 


age is priced at $195. Source code 
is available. 


Whitesmiths, Ltd. have been 
very busy of late tuming out 
upgrades and new products like 
there was no tomorrow. These 
include the following cross com- 
pilers: Gould-to-8086, Pyramid-to- 
8086, VAX-to-PDP-11 and VAX- 
to-680x0. Watch out for their 
native VAX compiler as well. All 
of these products are version 3 
which closely reflects the current 
draft ANSI Standard. (Note, how- 
ever, that their new PDP-11 com- 
piler ONLY runs on a CPU with 
I/D space under RSX-11M-PLUS.) 
If that’s not enough, they have for- 
mal arrangements with international 
affiliates to sell each other’s pro- 
ducts which will give Whitesmiths 
access to some 50 new cross com- 
piler combinations. They have also 
moved to 59 Power Rd, Westford, 
MA 01886. (617) 369-8499. 


I recently played with Green- 
leaf Software’s new DataWindows 
product and it is fast and has plenty 
of utility. Call them on (214) 631- 
0811 for a copy of their demo 
disk...Lattice has released V3.1 of 
their VAX/VMS and UNIX-based 
cross-compiler for DOS. Extensive 
Support for the proposed ANSI 
Standard is included. Price begins 
at $5,000 and includes a linker. 
Annual maintenance fee is 10% of 
cost. (312) 858-7950. Their DOS- 
based V3.2 compiler supports 
Microsoft’s C extensions far, 
near and pascal enabling it to 


work in conjunction with Microsoft 
Windows. Updates from V3 are 
free, from V2.x, $75. 


The Programmer’s Shop, a 
source of most DOS-based C tools, 
has produced a lengthy report cov- 
ering many C-related items includ- 
ing a detailed look at Microsoft C 
V4. Call them on (800) 421-8006 
or (617) 826-7531 and ask for a 
copy of The C Test...Pioneering 
Controls Technologies has 
released REAL-TOOLS, a set of 
UNIX development tools and C 
libraries designed to enhance pro- 
ductivity. Includes screen and win- 
dowing routines, graphics and other 
capabilities. Price is $99 for binary, 
$299 for library source, and $399 
for complete source. Supports 
UNIX System V and Xenix. 
Readily reported to other UNIX 
environments. (713) 266-UNIX. 


Pennington Systems has 
announced XTRAN, a translator of 
DEC assembler to C. It currently 
converts both MACRO-11 and 
VAX MACRO. They are also 
investigating the possibility of other 
assembly languages. They also 
offer their program translation ser- 
vices on a consulting basis. Pen- 
nington has long been involved in 
program translators starting with 
CONPAX, a PDP-to-VAX assem- 
bly convertor. (609) 737-2727. 


Catalytix Corp has announced 
the availability of their Safe C pro- 
duct line on the Cromemco UNIX 
system. (617) 497-2160. Also 
included is a version of Alan 
(Unsigned continued on p. 55) 
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Whitesmiths has multi-segment linker 


focused its efforts es Yo i | for generating ROM- 
solely on developing On The Machine OU Se. based code, and the 


and supporting a ability to display high- 
family of quality systems software. Today, Whitesmiths is level source code, assembly language, and machine object 
the only company offering compatible C and Pascal native code on one listing. 
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Version 3.0 of Whitesmiths compilers is now 
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designed to meet the needs of today’s 
professional software developers. Features 


The Version 3.0 Pascal compiler provides you 
with a Pascal to C Translator, a full ISO Level 1 
implementation that includes conformant array 
parameters and numerous extensions. 

If you're in the market for C or Pascal, call 
include a C source level Whitesmiths at 1-800-225-1030. 
interactive debugger with We have the compiler you want 


breakpointing and variable Whit e smiths, Lt d. for your machine. 
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S.A.R.L., 52 Quai des Carrieres, 94220 Charenton Le Pont, Paris, (14) 378-8357 ¢ GERMANY, GEl, Gesellschaft fuer Elektronische, Informationsverarbeitung MBH, 
Pascalstrasse 14, D-5100 Aachen, 02408/13-0 ¢ JAPAN, Advanced Data Controls Corp., Nihon Seimei Otsuka Bldg., #13-4, Kita Otsuka 1-Chome, Toshima-ku, Tokyo 
170, (03) 576-5351 ¢ SWEDEN, Unisoft AB, Fiskhamnsgatan 10, S-41455 Goteborg, (31) 125810 ¢ SWITZERLAND, RETIS, Realtime Software AG, CH-5001 Aarau, 
Bahnhofstrasse 96, (64) 247777 ¢ UNITED KINGDOM, Real Time Systems Ltd., P.O. Box 70, Douglas, Isle of Man, (624) 26021. 
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urbo C: The 

fastest, most 
efficient and easy- 
to-use C compiler at 
any price 


Compilation speed is more than 
7000 lines a minute, which makes 
anything less than Turbo C an 
exercise in slow motion. Expect 
what only Borland delivers: Quality, 
Speed, Power and Price. 


Turbo C: The C compiler 
for amateurs and 
professionals 

If you’re just beginning and 
you've “kinda wanted to learn C,” 
now’s your chance to do it the easy 
way. Like Turbo Pascal, Turbo C’s 
got everything to get you going. 

If you’re already programming 
in C, switching to Turbo C will 
considerably increase your produc- 
tivity and help make your programs 
both smaller and faster. Actually, 
writing in Turbo C is a highly 
productive and effective method— 
and we speak from experience. 
Eureka: The Solver™ and our. new 
generation of software have been 
developed using Turbo C. 


Sieve benchmark (25 iterations) 


Benchmark run on a 6 Mhz IBM AT using Turbo C version 1.0 and the 
Turbo Linker version 1.0; Microsoft C version 4.0 and the MS overlay linker 
version 3.51; Lattice C version 3.1 and the MS object linker version 3.05. 


4585 SCOTTS VALLEY DRIVE 
SCOTTS VALLEY, CA 95066 
(408) 438-8400 TELEX: 172373 
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Turbo C 


Turbo C: a complete 
interactive development 
environment 


Like Turbo 


Spr, i 
pea Pascal® and 


With 


=~ Turbo C comes 
with an interactive editor that will 
show you syntax errors right in your 
source code. Developing, debug- 
ging, and running a Turbo C 
program Is a snap. 


Turbo C: The C compiler 
everybody's been 
waiting for. Everybody 
but the competition 


Borland’s “Quality, Speed, Power 
and Price” commitment isn’t idle 
corporate chatter. The $99.95 price 
tag on Turbo C isn’t a “typo,” it’s 
real. So if you'd like to learn C ina 
hurry, pick up the phone. If you're 
already using C, switch to Turbo C 
and see the difference for yourself. 


System requirements 


IBM PC, XT, AT or true compatibles. PC-DOS (MS-DOS) 
2.0 or later. One floppy drive. 320K. 


*Introductory price—good through July 1, 1987 


Technical Specifications 


[™{ Compiler: One-pass compiler 
generating linkable object modules 
and inline assembler. Included is 
Borland’s high performance “Turbo 
Linker.” The object module is com- 
patible with the PC-DOS linker. Sup- 
ports tiny, small, compact, medium, 
large, and huge memory model 
libraries. Can mix models with near 
and far pointers. Includes floating 
point emulator (utilizes 8087/80287 
if installed). 


[{ Interactive Editor: The system 
includes a powerful, interactive full- 
screen text editor. If the compiler 
detects an error, the editor auto- 
matically positions the cursor 
appropriately in the source code. 


| 
| 
| & Development Environment: A 
| 
| 


powerful “Make” is included so 
that managing Turbo C program 
development is highly efficient. 
Also includes pull-down menus 
and windows. 


[@ Links with relocatable object 
modules created using Borland’s 
Turbo Prolog into a single program. 

| [™{ ANSI C compatible. 


[4 Start-up routine source code 
included. ° 


(4 Both command line and integrated 
environment versions included. 


| 


Turbo C and Turbo Pascal are registered trademarks and Turbo Prolog 
and Eureka: The Solver are trademarks of Borland International, Inc. 
Microsoft C and MS-DOS are registered trademarks of Microsoft Corp. 
IBM, XT, and AT are registered trademarks of International Business 


Machines Corp. Copyright 1987 Borland International Bl-1104 


— 


For the dealer nearest you or to order by phone call 


(800)255-8008 


in CA (800) 742-1133 in Canada (800) 237-1136 
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